[m-rev.] field syntax (was: smart recompilation)

[Fergus Henderson]

On 04-Jul-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> 
> I don't see what the problem is.  I find the field access stuff easiest
> to understand as a syntactic transformation.

If I see

(1)	X = get_bar(get_foo(Y))

then I can figure out pretty quickly that this is probably getting the
"foo" field of Y, and then extracting the "bar" sub-field of that.
I may not know what "foo" and "bar" are, but I can start drawing
a mental picture of a term (named Y) containing a foo containing
a bar (named X).

If, on the other hand, I see

(2)	X = bar(foo(Y))

then I will start to draw a very different mental picture.
There'll be Y, another object which I'll call Foo, and X,
and there'll be an arc from Y to Foo labelled foo and
an arc from Foo to X labelled bar.

I want the X = Y^foo^bar syntax to correspond to the first mental picture.
But because it syntactically expands to (2) rather than to (1) or something
equivalent to (1), I can't be confident that that picture is accurate.
This makes it harder to reason about the code.

> > I also think it's a bit of a wart in the current design that you can
> > write a
> > 	X = "hello" ^ to_upper
> > 
> > but to_upper is not a field access function and was never intended to
> > be one.
> 
> Are you saying that it is bad style to use field access functions
> for other purposes

Yes!

Field access functions should only be used for things where conceptually
the field value being returned can reasonably be considered a
sub-component of the object whose field is being extracted.

> and that the language should forbid such things?

I don't think that is possible, because I don't think it is possible to
formalize or statically check the notion outlined above.

But I think coding standards should forbid it.

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