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

Fergus Henderson fjh at cs.mu.OZ.AU
Mon Sep 4 13:36:55 AEDT 2000


On 01-Sep-2000, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> +:- type goal_rep
> +	--->	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.

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.

It might be a good idea to have a field here saying what kind of
conjunction it is.  For certain kinds of bugs, e.g.  when you get an
exception but didn't expect to, it can make a difference.

> +	;	unify_assign(
> +			var_rep,
> +			var_rep
> +		)

Which is the source and which is the target of the assignment?
It would be a good idea to include field names in all these structs,
to document things like this.

> +	;	method_call(
> +			var_rep,
> +			int,
> +			list(var_rep)
> +		)

What's the `int' here?

> +	;	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.)

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

s/multidet/multi/g

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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