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

Zoltan Somogyi zs at cs.mu.OZ.AU
Fri May 28 13:08:01 AEST 1999

Warwick wrote:
>>> +Declare_entry(mercury__unused_0_0);
>>> +MR_STATIC_CODE_CONST struct mercury_data___type_ctor_info_succip_0_stru
       ct {
>>> +	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?

The compiler creates field names like that when declaring structures
to hold statically allocated structures. The reason why the compiler
declares one structure per data item is that different items, even of the same
general kind, may have different type values in the same field, due to
our use of techniques such as using one slot which may contain either
a small integer or a pointer.

The hand-written type_ctor_infos were, I believed, originally cut-and-pasted
from compiler-generated ones; hence the names.

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

Yes. If I were you, I'd change all field names in such structures on the trunk.

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