[m-dev.] for review: removing redundant inst info from layout structures

Warwick Harvey wharvey at cs.monash.edu.au
Thu May 27 17:17:00 AEST 1999


> > +Declare_entry(mercury__unused_0_0);
> > +MR_STATIC_CODE_CONST struct mercury_data___type_ctor_info_succip_0_struct {
> > +	Integer f1;
> > +	Code *f2;
> > +	Code *f3;
> > +	Code *f4;
> > +#ifdef USE_TYPE_LAYOUT
> > +	const Word *f5;
> > +	const Word *f6;
> > +	const Word *f7;
> > +	const Word *f8;
> > +	const Word *f9;
> > +#endif
> > +} mercury_data___type_ctor_info_succip_0 = {

Just out of curiosity (well, not *just* from that...), is there any 
particular reason these fields in the type_ctor_info structures are named 
"f1", "f2", etc.?  They're not ever referenced by name, are they?

It would seem to me that if they were given more meaningful names (not 
*much* more meaningful names --- short would seem to be good in this context 
--- but at least symbolic rather than numeric) then:

a)  They'd be a little easier to understand, with certain kinds of 
cut-and-paste errors easier to spot/verify.

b)  There'd be fewer/easier to resolve CVS conflicts between those of us who 
add or modify these structures.

If this seems reasonable, it might be something I'd be willing to do next 
time I either:

i)  Add a new field in the main branch of the compiler (e.g. a customisable 
print predicate).

ii)  Merge changes from other branches into the HAL branch which would cause 
conflicts anyway.

Comments?

Warwick

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