[m-dev.] for review: MR_TypeInfo cleanup, part 3 (of 3)
Zoltan Somogyi
zs at cs.mu.OZ.AU
Fri Mar 24 16:09:56 AEDT 2000
On 23-Mar-2000, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > +#define usual_func MR_make_type_info
> > +#define exist_func MR_make_type_info_maybe_existq
> > +#define exist_func_string "MR_make_type_info_maybe_existq"
> > +#define MAYBE_DECLARE_ALLOC_ARG , MR_MemoryList *allocated
> > +#define MAYBE_PASS_ALLOC_ARG , allocated
>
> I would find "yes" and "no" as perhaps better values for the last two,
> then the code can do this by itself (using #ifdefs).
> This makes the little language you are defining here simpler.
> (If there were 3 possible values for this #define then this would
> probably be OK).
The current scheme makes mercury_make_type_info_body.h fully independent
of the details of memory allocation. Your suggestion would destroy that
independence. In particular, it would mean that mercury_make_type_info_body.h
contains (conditionally compiled) references to an argument, which it then
does not contain (even conditionally compiled) code to use. I suppose one
could go the whole hog and include (both versions of) *all* memory management
code in mercury_make_type_info_body.h, selected by a boolean switch, but I
think the current scheme is preferable both on grounds of cleanliness and
because it is more adaptable (e.g. to native gc).
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