[m-dev.] for review: program_representation.m

[Zoltan Somogyi]

On 04-Sep-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > +	--->	conj(
> > +			list(goal_rep)		% The conjuncts in reverse
> > +						% order.
> > +		)
> 
> Why are these stored in reverse order?
> 
> I think it would be much more natural (and less bug-prone)
> to store them in the original order.

Because the data structure is for the declarative debugger, which always
needs it in reverse order in all its time critical operations (that we can see
now, at any rate). Requiring a statically allocated list to be reversed
dynamically many times would be a bad idea.

> What about parallel conjunctions?
> Do they get mapped to `conj' in this representation?
> For parallel conjunctions, the conjuncts are really unordered,
> so hopefully nothing in the declarative debugger should depend
> on the ordering.

Debuggable code that actually uses coroutining will generate events
in sequences that will confuse the current declarative debugger anyway,
so par_conjs will not be handled for the time being. I plan to report
a "sorry, not implemented" error from the compiler for par_conjs and
for calls to Aditi.

> > +	;	unify_assign(
> > +			var_rep,
> > +			var_rep
> > +		)
> 
> Which is the source and which is the target of the assignment?

Same order as the in the HLDS, as the comment on top says.

In this case, in a sense it doesn't matter, since the list of bound vars
will identify the var being bound.

> It would be a good idea to include field names in all these structs,
> to document things like this.

In this case, the type has several function symbols. Given that and the fact
that the order of fields is long familiar, I don't think field names would
help.

> > +	;	method_call(
> > +			var_rep,
> > +			int,
> > +			list(var_rep)
> > +		)
> 
> What's the `int' here?

As in the HLDS, it is the method number.

> > +	;	plain_call(
> > +			string,
> > +			list(var_rep)
> > +		).
> 
> What's the `string' here?
> I guess it is probably the predicate/function name.
> But does it include the module qualifier?
> 
> Shouldn't you include an indication of whether it is a predicate
> call or a function call, so that the declarative debugger can
> print out calls using the right syntax?
> (The same applies for method calls and generic calls.)

The detailed format is up in the air for now. It has to be sufficient
to allow the declarative debugger to get to the proc layout of the called
procedure. Once you have that, you have everything the user interface needs.

> > +:- type detism_rep	
> > +	--->	det
> > +	;	semidet
> > +	;	nondet
> > +	;	multidet
> > +	;	cc_nondet
> > +	;	cc_multidet
> > +	;	erroneous
> > +	;	failure.
> 
> s/multidet/multi/g

In prog_data.m, it is still multidet.

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