[m-rev.] for review: atoms in the debugger

[Fergus Henderson]

On 02-Jan-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> What??? This change has *nothing* to do with closures or higher order terms.

Sorry, my mistake, as I realized shortly after posting that.
See my other message.

> > > browser/browser_info.m:
> > > 	Define a new type, browser_term, which represents either a plain term,
> > > 	or a "synthetic term", which is a string (predicate or function name),
> > > 	a list of argument values, and an indication of whether the synthetic
> > > 	term is a predicate atom (i.e. of the form p(a1, ..., an)) or a
> > > 	function atom (i.e. of the form f(a1, ..., an-1) = an).
> > 
> > Why do these two need to be handled differently?

By "these two" I meant plain terms and synthetic terms, not
predicates and functions.  But now that I understand that
synthetic terms are used for the terms used to represent calls,
I know why they need to be handled differently.

A brief comment in the definition of the synthetic_term type explaining
what they are used for (rather than just what they are) might help.

> (The verbose format ignores the distinction, at least for now, because I
> don't know that code well enough to position the equal sign well.)

There should be an XXX comment for that, I hope.

> > > +		list__length(Args, Arity),
> > > +		(
> > > +			IsFunc = yes,
> > > +			PrincipalSize = FunctorSize + 1 + Arity * 2
> > > +		;
> > > +			IsFunc = no,
> > > +			PrincipalSize = FunctorSize + Arity * 2
> > 
> > Comments here explaining the rationale for these magic formulae would help.
> 
> No it wouldn't. The formulae are an obvious consequence of the task of the
> predicate and the meaning of the input data.

It wasn't obvious to me.
I had to think about it for a fair bit.

If it was written as

		list__length(Args, PredArity),
		(
			IsFunc = yes,
			FuncArity = PredArity - 1,
			% 3 for " = ", 2 per argument for ", "
			PrincipalSize = FunctorSize + 3 + FuncArity * 2
		;
			IsFunc = no,
			% 2 per argument for ", "
			PrincipalSize = FunctorSize + PredArity * 2
		)

or as

		list__length(Args, PredArity),
		(
			IsFunc = yes,
			FuncArity = PredArity - 1,
			PrincipalSize = FunctorSize
				+ FuncArity * string__length(", ")
				+ string__length(" = ")
		;
			IsFunc = no,
			PrincipalSize = FunctorSize
				+ PredArity * string__length(", ")
		)

then I think it would be easier to understand and maintain.

In fact, now that I write it out like that and think about it a bit more,
it looks to me like the original formula had a bug -- isn't the formula wrong,
because it doesn't take into account the sizes of the "(" and ")"?

> > > +browser_term_compress(BrowserTerm, Str) :-
> > > +	functor_browser_term(BrowserTerm, Functor, Arity, IsFunc),
> > >  	( Arity = 0 ->
> > >  		Str = Functor
> > >  	;
> > > +		(
> > > +			IsFunc = yes,
> > > +			int_to_string(Arity - 1, ArityS),
> > > +			append_list([Functor, "/", ArityS, "+1"], Str)
> > 
> > Hmmm, you're abbreviating function terms as `foo/N+1',
> > (e.g. `std_util:yes/1+1').
> > 
> > The usual abbreviation would be without the `+1' at the end.
> 
> This is not an error message for a function application. It is a compressed
> representation for an atom. Deleting the +1 would be misleading.

Why?

> std_util.m has no function named "yes", so your example is fictional.

True.  "int:'+'/2+1" would have been a better example.

> The code here is not applied to function symbols. Unlike function symbols,
> functions do have an extra argument.

Functions don't have an extra argument.  The predicates that the Mercury
compiler transforms functions into have an extra argument, but that is an
implementation detail which should not be visible to the user.  A different
implementation might transform function symbols (data constructors) to
constructor procedures which had an extra argument.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------