[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