[m-dev.] diff: bootstrap problem with init files in hlc grade

Fergus Henderson fjh at cs.mu.OZ.AU
Wed Nov 8 03:57:12 AEDT 2000


On 06-Nov-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 05-Nov-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > The cost of that in terms of code size and efficiency is trivial.
> > But for the MLDS back-end I want to optimize not just the efficiency
> > but also the readability of the generated code.  In terms of readability,
> > the cost is small, but not entirely trivial, so it would be nice if we
> > could avoid it.  Could you elaborate on what kind of future problems you're
> > trying to forestall here?
> 
> Actually, one problem I am trying to forestall can be fixed *only* by
> generating such a function all the time. The problem is that with the old
> setup, the programmer does not usually see an initialization function being
> generated, and may decide to use that name for their own initialization
> (even though the name starts with mercury_, they may not know that such names
> are reserved). This will work fine *until* they compile their program with
> profiling.
>
> In general, I think that not having the set of functions generated for a module
> depend on the options *improves* readability.

Well, that might justify having the functions generated.
But it doesn't justify them having non-empty contents.
In particular the calls to MR_init_entry() that do nothing go against
the MLDS philosophy of not relying on macros and #ifdef.
Also the stuff fooling around with `static int initialized' certainly
doesn't improve the readability.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- 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
--------------------------------------------------------------------------



More information about the developers mailing list