[m-dev.] C types from .m files, optimisation files, references, and everything...

[Fergus Henderson]

On 23-Aug-1999, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> I was wondering whether it was possible to share a C type defined in one 
> Mercury module with other Mercury modules?

Yes, it is possible.

> I expect the correct answer is 
> "Stick it in a `.h' file."  And that's what I'll probably end up doing.

That certainly works, and it is probably the best solution.

(If you are exporting at least one Mercury procedure to C via `pragma export',
then putting it in `pragma c_header_code' and then #including the
automatically-generated C header file for the Mercury module will also
happen to work, I think, at least with the current implementation.
But using creating a C header file yourself is probably a much better idea.)

> But 
> if anybody is interested, I wouldn't mind some opinions on some of the 
> issues solving the "real" problem I'm working on.
> 
> In the HAL implementation, we use a couple of quite ugly hacks and exploit 
> undocumented features to get what we want.  :-)  One of these hacks was used 
> in the implementation of global variables, and we just discovered that the 
> hack appears to have been broken back in April or so (we only just noticed 
> because some other features have been added to HAL so that now global 
> variables actually start being useful).  Anyway, I can see three (or so) 
> ways of fixing the implementation, with varying levels/kinds of hackiness, 
> plus some efficiency issues.  But I'm getting ahead of myself...
> 
> The hack in question involves getting access to the ME_Reference C type 
> defined in extras/references/reference.m.  Basically, we want static 
> ME_References, not ones allocated on the heap (which is where the reference 
> module puts them).  At the time I was first doing this, it seemed like the 
> sort of stuff we wanted to do was too ugly to go into the Mercury 
> distribution, and I wanted to avoid double-maintenance as much as possible, 
> so I looked for a compromise.  The solution I came up with was to turn on 
> inter-module optimisation, and lo, any module importing the reference module 
> suddenly had access to anything defined in the c_header_code sections; in 
> particular, the ME_Reference type.  :-)
> 
> This seemed to work fine, but it doesn't any more.

Yes, the effect that you noticed is certainly not a documented feature;
you shouldn't rely on it.

> The problem is that the 
> c_header_code from imported modules now appears to be inserted *after* the 
> c_header_code from the importing module.  This means I'm trying to use the 
> type before it's defined.  :-(  The "minimal" fix would presumably be to 
> change the compiler so that it spits the c_header_code chunks out in a 
> different order.  That of course isn't a particularly "nice" solution, and 
> has the drawback that I have been unable to find the part of the compiler 
> that does this.  :-)

In the current implementation, the items from imported modules occur
after the items from the importing module in the item_list (the parse
tree).  This is the case not just for `pragma c_header_code' but for
all other kinds of items too.  The code which deals with the
`pragma c_header_code' declarations then just preserves the order
in the parse tree.

The relevant code is in modules.m, specifically the `grab_imported_modules'
predicate (see also the `grab_unqual_imported_modules').

> (Note that just reversing the chunks would not work 
> since then multiple chunks from the one original file would come out in 
> reverse order, which would no doubt cause problems.)
> 
> The other two solutions I see leave the compiler as it is, and stop using 
> the hack (which is presumably a good thing ;-).

Yes, you shouldn't rely on that.

> In the second version, we move the definition of the ME_Reference structure 
> into a header file, so that other modules can declare variables of that 
> type.

That sounds to me like the best approach.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------