[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