[m-rev.] diff: move library changes on the mode-constraints branch onto trunk

[Fergus Henderson]

On 04-Mar-2003, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 26-Feb-2003, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > +#include ""../robdd/bryant.h""
> > > +").
> > > +
> > > +:- pragma foreign_code("C", "
> > > +#include ""../robdd/bryant.c""
> > 
> > The hard-coded "../robdd/" path names here are a problem.
> > How will that work when the header files get installed into
> > <prefix>/lib/mercury/inc?
> 
> The one in foreign_code isn't a problem, as it doesn't get included
> in the .mh file in that directory. The one in the foreign_decl does,
> but I am not *sure* why. The language reference manual doesn't say anything
> about this, and since the only effects of a foreign_decl it discusses apply
> only to the compilation of the code in the relevant module, implies that
> this shouldn't happen.

The language reference manual could probably be improved.
Do you have a specific suggestion for improved wording?

> I think the reason why we include foreign_decls in .mh files is because
> they may declare types needed by :- exported procedures. 

That is one reason.  The relevant patch was this one:

     | RCS file: /home/mercury1/repository/mercury/compiler/mlds_to_c.m,v
     | Working file: mlds_to_c.m
     | revision 1.136
     | date: 2002/08/05 21:46:13;  author: petdr;  state: Exp;  lines: +16 -6
     ...
     | Record foreign_decls in the .mh file.
     | This fixes a bug where a definitions of pragma exported functions where
     | refereing to undefined pragma foreign_type names.
     ...
     (see the full log for more details).

However, C declarations in pragma foreign_decl may also be used by
C code in pragma foreign_proc which gets intermodule-inlined.
Before that patch, we used to put pragma foreign_decls in `.opt' files,
and thereby copy them into all the generated `.c' files which might need them;
after that patch, the generated `.c' files just include the `.mh' file.

> However, not
> all foreign_decls do that, and for the ones that don't, including them
> in the .mh file may be harmful, as here.

All `pragma foreign_decl's should declare something that will be
referenced by `pragma foreign_proc' (or `pragma import', which is just
syntactic sugar for a special case of `pragma foreign_proc').
So for intermodule optimization they all need to be included in the
`.mh' file.

> (Regardless of path names,
> anyone importing robdd.mh will need to make a robdd.h file visible to the
> C compiler, which shouldn't be necessary; robdd.h is needed only when
> generating robdd.o.)

That is not true in the presence of intermodule optimization.

> > > +:- pragma foreign_proc("C",
> > > +	one = (F::out),
> > > +	[will_not_call_mercury, promise_pure],
> > > +"
> > > +	F = (MR_Word) MR_ROBDD_trueVar();
> > > +").
> > 
> > The cast to MR_Word here (and in lots of other places in this file)
> > is wrong for --high-level-data.  It will need treatment similar to what
> > runtime/mercury_hlc_types.h does for the builtin types.
> > Or alternatively (probably better), use `pragma foreign_type'.
> 
> OK, I am now using a type which is either MR_Box or MR_Word depending
> on the backend.

I don't think MR_Box is correct.  I think it should be
`struct mercury__robdd__robdd_1_s *' or something like that.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------