[m-dev.] for review: automatic header file inclusion guards.

[Tyson Dowd]

On 26-Jan-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > Anyway, I don't want to waste time pushing this change past people who
> > don't want it.  The other way to do this is to hash the contents of the
> > foreign_decl string -- so I will write some code to do this instead.
> 
> That doesn't sound like a good idea either.  To avoid hash collisions,
> you'd need a cryptographically secure hash function, and that might be
> expensive to compute.  Furthermore, it's not the right semantics,
> since if the user writes the same `foreign_decl' twice, it should get
> included in their program twice, but what you propose would only
> include it once.

You say "if the use writes the same `foreign_decl' twice, it should get
included in their program twice".

But with the current implementation a single foreign_decl can be
included any number of times (by #including and .opt file propogation).
The number of times it is included in the program has no relationship
with the number of foreign_decl pragmas.

If you meant "included in the same scope twice", then for C code this is
not useful at all.  In C, the same declarations given twice
can only mean redeclaring exactly the same things, or giving a duplicate
declaration error message (I think typedefs do this).  Neither of these
leads any further expressiveness.

This is all a bit dicey, because we haven't really defined the meaning
of foreign_decl.  But I think it should be defined along the lines of 
	"The declarations will be visible to any foreign_code in
	this module".
It should *not* be defined as
	"The declarations will be pasted into the text of the program
	once for each foreign_decl pragma".

If you want to get this, then you should use foreign_code, which should
have semantics such as:
	"Each foreign code fragment will be compiled and included in the
	program".
(this implies that multiple foreign code fragments will be compiled and
included multiple times).

The cryptographically secure hash function is md5.  
I don't think it is expensive enough to be worried about (about 0.5
seconds to do 13Mb of text), 0.15 seconds to do all the 765 .m files in
the tests module).

> I think a better approach, at least for the MLDS back-end, would be to
> ensure that each foreign_decl gets written to exactly one header file,
> namely the one corresponding to the module that defined it.  Other C
> files which might need those declarations should #include that header
> file, rather than containing a copy of the foreign_decl.  In other words
> the MLDS back-end should discard foreign_decls read from `.opt' files,
> and just make sure sure that it #includes all the necessary headers.

This is reasonable too.  But it means you cannot put foreign_code from
another module into your .opt or .trans_opt file, because the
foreign_code doesn't have a context attached to it, so you cannot tell
where you are supposed to include the .h file from.  I don't think we
do this sort of optimization at the moment, but it sounds like one we
should do someday.

(BTW, what mechanisms are there to avoid namespace clashes with
automatically generated .h filenames?).

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------