[m-dev.] Re: conditional compilation

Julien Fischer juliensf at csse.unimelb.edu.au
Thu Jan 7 05:04:03 AEDT 2010


On Wed, 6 Jan 2010, Peter Wang wrote:

> On 2010-01-06, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>>
>> Hi all (and happy new year),
>>
>> On Tue, 5 Jan 2010, Peter Wang wrote:
>>
>>> On 2010-01-05, Paul Bone <pbone at csse.unimelb.edu.au> wrote:
>>>> On Tue, Jan 05, 2010 at 05:41:08PM +1100, Peter Wang wrote:
>>>>>
>>>>> With conditional implementation sections I could cleanly separate the
>>>>> two completely different implementations, while providing the single
>>>>> module interface.
>>>>
>>>> An extra benefit that we can get here is that the 'disabled' sections can be
>>>> error checked but not compiled.  This can help us verify that these sections
>>>> are correct even when they aren't applicable to the current backend/platform.
>>>
>>> Actually, probably not.
>>
>> I am strongly opposed to not always checking the conditional
>> sections.  We already have this problem to some extent with Mercury
>> clauses not being checked in the presence of foreign clauses.
>> I definitely do not want C style conditional compilation (i.e. no
>> checking of the alternatives) in Mercury.
>
> That would only remain possible with simpler conditions, e.g. based on
> the foreign language only.
>
> I don't think conditional sections will be needed all that often.
> In the situation I described, the altenatives are to:
>
>    - clutter the source with a heap of dummy foreign procs
>    - use a preprocessor to cut out irrelevant code
>    - use different files implementating the same module
>
> all of which are designed to bypass the compiler checking anyway.

True, but that doesn't mean I have to like it! ;-)

How about this: add a pragma that that marks certain procedures as being
conditional on something, e.g.

     :- pragma conditional_proc(foo/2, [<conditions>]).
     :- pred foo(io::di, io::uo) is det.

* the conditional_proc/2 pragmas (or whatever they end up being called)
would be written out to the .int0 files - so when sub-modules are being
compiled we can check whether any calls to conditional procs in the
sub-module are consistent with the conditions in the conditional_proc/2
pragma.

* this should be able to be implemented without restructuring the parse tree.

* once the parse tree has been restructured then the conditional
implementation sections can be implemented in terms of a
source-to-source transformation involving the above.

[the new pragma would not be allowed on exported procedures]

>> Some other observations related to this thread:
>>
>> (1) the reference manual doesn't actually specify what an implementation
>> (or for that matter, interface) section is.  There is a long standing
>> XXX regarding this.
>>
>> (2) It seems that with this feature then private interface files, .int0,
>> will depend upon what compiler flags are given, i.e. they will have to
>> become grade dependent (they currently aren't).
>> (This assumes that the visibility rules for conditional implementation
>> sections w.r.t to sub-modules are the normal ones.)
>
> Grade-dependent won't be enough for arbitrary conditions.  Perhaps the
> implementation sections will have to be kept and written out to to
> interface files with their conditions.  I'm not sure.
>
> .int files also contain a few things from implementation sections.

Yes, but we try go keep that to a minimum since it (obviously) affects
recompilation.  I think this only really affects .int0 files - not the
others.

Julien.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the developers mailing list