[m-dev.] for review: register type_ctor_infos, part 2

Zoltan Somogyi zs at cs.mu.OZ.AU
Mon Oct 30 20:03:16 AEDT 2000


On 30-Oct-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > 	Note that this code is in the usual initialization function, the one
> > 	called by do_init_modules(). Putting this code in a separate
> > 	initialization function that is called by do_init_modules_type_tables()
> > 	would require complicating mkinit.c considerably.
> 
> I must be missing something...
> what extra complication would be required in mkinit.c?

Basically, there are two alternatives. One alternative is to require
every handwritten module to have three initialization functions, just
as the automatically generated modules do. This puts extra burdens on people
who write such modules, some of whom may be (e.g.) in Europe. The other
alternative is to have some kind of naming scheme for the names of hand-written
modules that would tell mkinit which initialization functions the handwritten
module had, so that mkinit could generate code to call only the initialization
functions that actually exist. The latter would call for extra extra code in
mkinit.c to handle the naming convention.

> If `cur_bunch' represents the number of function calls output so far
> in the current function, then I think `num_calls_in_cur_func'
> would be a better name.
> 
> I think it would be clearer if `filebunches' was named
> `num_<something>' (throughout).

I think num_calls_in_cur_func is confusing because it does not say what
function you are talking about. Instead, I have documented the notion of
bunches and did s/filebunches/num_bunches/ and
s/cur_bunch/num_calls_in_cur_bunch/.

> What's that code inside `#if 0' for?

It was part of an attempt to get mkinit.c to generate code to initialize
(and thus link in) the browser only if mkinit was invoked with --trace,
but later I decided to handle this in the c2init script instead. I will
remove the dead code.

Zoltan.
--------------------------------------------------------------------------
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