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

[Zoltan Somogyi]

On 02-Jan-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> 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.

There was already such a comment, it was just in the second file in the diff,
not the first.

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

I added one.

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

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

Both of these would be *harder* to understand and maintain, because they are
wrong; see below.

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

No, there is no bug; your thinking has a fencepost error. In the term
p(a1, a2, a3, a4), there are three ", " strings and one pair of "()".
Overall, this is 4 * 2 characters.

I added the comments

	% "()", plus Arity-1 times ", "

and

	% "()", " = ", plus Arity-2 times ", "

in the two arms.

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

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

They have a return value that may be available for browsing. That is what the
+1 represents. Whether it is an argument or not is an implementation detail,
and printing function calls as "list__length([1, 2]) = 2" instead of
"list__length([1, 2], 2)" when using the function form of list__length
is meant to *avoid* exposing the implementation detail.

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

I agree, but this doesn't help your argument.

> A different
> implementation might transform function symbols (data constructors) to
> constructor procedures which had an extra argument.

If that ever happened, I would agree that this should be kept hidden.
However, that is not an issue now, and even when it does arise it should
be easy to handle.

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