[m-rev.] for review by Mark: synthesized attributes

Zoltan Somogyi zs at csse.unimelb.edu.au
Thu Dec 14 14:12:58 AEDT 2006


On 13-Dec-2006, Mark Brown <mark at csse.unimelb.edu.au> wrote:
> > +** The synth_attr_order field points to an array of attribute numbers that
> > +** gives the order in which the values of the synthesized attributes should be
> > +** evaluated. The array is ended by -1 as a sentinel.
> 
> Are the synthesized attributes always going to be calculated all at once?
> If not, it might be better to represent the dependency graph rather than an
> ordering, so that the number of attributes synthesized can be minimized.

So far, they are always materialized all at once. However, the MR_SynthAttr
structures do give the dependency graph as well. I added the max number of
attributes field to the module layout specifically so that it in the future,
any code that wants to materialize synthesized attributes only one-by-one,
on demand, can allocate an array of booleans of this size, to keep track
of which synthesized attribute has so far been materialized.

I thought of adding an extra field to each MR_SynthAttr structure, to say
"you must materialize these other attributes before you can materialize this
one", but it turns out relation.m doesn't export the functionality that
prog_event.m would need to generate this field.

> > -struct MR_UserEvent_Struct {
> > -	MR_uint_least16_t		MR_ue_port_number;
> > -	const char			*MR_ue_port_name;
> > -	MR_uint_least16_t		MR_ue_num_attrs;
> > -	MR_LongLval			*MR_ue_attr_locns;
> > -	MR_TypeInfo			*MR_ue_attr_types;
> > -	const char			**MR_ue_attr_names;
> > -	const MR_uint_least16_t		*MR_ue_attr_var_nums;
> > +struct MR_SynthAttr_Struct {
> > +	MR_int_least16_t		MR_sa_func_attr;
> > +	MR_int_least16_t		MR_sa_num_arg_attrs;
> > +	MR_uint_least16_t		*MR_sa_arg_attrs;
> 
> Those two fields have their type swapped: the number of attributes should
> be unsigned and the attribute numbers should be signed.

No, what is there is right. For nonsynthesized attributes, the compiler
sets the first two fields to -1, since 0 is both a valid attribute number
and a valid number of arguments. The attribute numbers themselves cannot be
negative.

> > +** For attribute value, the num field gives the position of this attribute
> 
> s/For attribute value/For all attributes/

I changed it to "For attribute valueS" ...

I followed your other suggestions.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list