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

Zoltan Somogyi zs at cs.mu.OZ.AU
Wed Jan 2 17:56:53 AEDT 2002


On 02-Jan-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 31-Dec-2001, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > Give the debugger the ability to print atoms.
> 
> As a matter of terminology, I don't think we should use the term "atom";
> instead we should use "closure" or perhaps "higher-order term",
> for consistency with the Mercury language reference manual.

What??? This change has *nothing* to do with closures or higher order terms.

> The term "atom" is a misnomer (they're decomposable, not atomic),
> and is confusing for people used to Prolog or Lisp terminology.

It is standard logic programming terminology. It is a misnomer only to the
extent it is a misnomer in physics itself. Any *other* name would be confusing
for people with logic programming backgrounds. Anyone with a Lisp background
would be far more confused by the peculiar placement of the Lots of Insane
Stupid Parentheses :-)

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

They don't *need* to be, but it would be nice to have the debugger print

	list__length([1, 2, 3], 3)

if you called the predicate version of list__length and

	list__length([1, 2, 3]) = 3

if you called function version.

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

> Are plain terms allowed to have higher-order types?
> Are synthetic terms allowed to be first-order,
> i.e. can they have a data constructor rather than a function name?

These questions do not make sense. None of this change has *anything* to do
with types. All it is concerned with is whether a term that you want to print
out is specified by a single Mercury term or by a string and a list of
argument terms. This code has no idea what the string represents. It could be
anything, although in this change the string passed to these predicates
will always be a predicate or function name.

> There should be comments in the interface section here
> explaining what these predicates do.

OK.

> > +		BrowserTerm = synthetic_term(Functor, Args, IsFunc),
> > +		string__length(Functor, FunctorSize),
> > +		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.

	list__length([1, 2, 3], 3)
	list__length([1, 2, 3]) = 3

As you can see, the latter is one character longer.

> > +			brack_args(PredArgStrs, BrackPredArgsStr),
> 
> It took me a long time to figure out what "brack" stood for here.
> So I suggest that you spell these out in greater length,
> e.g. "bracket_args" instead of "brack_args".
> and BracketedPredArgsStr instead of BrackPredArgsStr.

Done.

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

std_util.m has no function named "yes", so your example is fictional.
The code here is not applied to function symbols. Unlike function symbols,
functions do have an extra argument.

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



More information about the reviews mailing list