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

Simon Taylor stayl at cs.mu.OZ.AU
Thu Jul 5 16:48:56 AEST 2001


On 04-Jul-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> 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.

The current system allows you to choose which mental model you want
to use. If you don't want to use field accessors as functions, you don't
have to. Your proposal makes things less convenient for people who don't
care about the distinction between field accessors and function applications
(they have to use quoted names, or wrapper functions to use field accessors
as functions).

>From the discussion so far, there seems to be a roughly 50-50 split
on which model people prefer. I think this is a coding standards issue.
The language should not enforce a choice either way.

Simon.

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