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

[Mark Brown]

On 04-Jan-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 04-Jan-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> > > > 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.
> > 
> > Not enough.
> 
> Indeed! 
> 
> Either my brain has stopped functioning properly (a definite possibility ;-),
> or it really isn't obvious.
> 
> > I added the comments
> > 	% "()", plus Arity-1 times ", "
> > and
> > 	% "()", " = ", plus Arity-2 times ", "
> > in the two arms.
> 
> Thanks.
> 
> > > > 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?
> > 
> > Because it would imply that there are only n-1 subterms available to be
> > browsed, when in fact there are n. It implies that the browser command "^n"
> > would fail, when in fact it would succeed.
> 
> OK, that makes sense.  If we're treating the function return value as the
> "Arity+1"th argument for the purpose of browsing, then I agree it's a
> good idea to use the +1 notation.
> 
> I'm not sure it's such a great idea to treat the function return value
> as the "Arity+1"th argument -- it might be better to use something different,
> e.g. "^r", to access the function return value -- but I'm not going to start
> redesigning that at this point.

I think it would be better to redesign this (although not necessarily as
part of this change).  The concept of a function's return value is
unique, in the sense that there is only one way for a value to be
returned from a call.  But with the above design there are many
different ways to refer to the return value, and only one of these can
be correct.  The arity of a function is unrelated to the concept of a
return value, so I think it is a mistake to expect the arity to be known
before the return value can be browsed (even though the arity is readily
available).

In particular, I think it is error prone if the last argument is of the
same type as the return value.  The user could accidentally browse the
last argument instead of the return value, and mistakenly conclude that
the function was not doing its job.  For example, the user may forget
whether the first argument is numbered 0 or 1.

So I agree that "^r" would be a good way to access the return value.

Another alternative, which may be easier to implement, is to treat
the return value as argument 0.  This has the advantage that the same
number is used for any function, regardless of arity.  It also fits the
way that functions are often used in goals:

	Z = f(X, Y)

Finally, it means that we could stick with the usual abbreviation of
terms as Name/Arity, without (IMHO) being misleading about the browser
commands available.

Cheers,
Mark.

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