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

[Tyson Dowd]

On 05-Jul-2001, Simon Taylor <stayl at cs.mu.OZ.AU> wrote:
> 
> 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.

I don't understand your point.
Field accessors are transformed into functions.  They are functions.
How can you possibly avoid using field accesors as functions except by
not using them at all.

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

Your support of the status quo makes things less convenient for people
who *do* care about the distinction between field accessors and function
applications.

My impression of the situation was that you normally can't use field
accessors as higher order functions without writing an explicit lambda
anyway (because they are multi-moded), so the loss of convenience in
using quoted names or wrapper functions is hardly a big deal.

I was hoping that the general case of using (but not defining
hand-written) field accessors with ^ would be exactly the same.

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

I don't understand this comment at all.

What is the coding standard issue?  What use of coding standards would
help people who wish to distinguish between field-like accessors
and plain function application?

What choice is the language going to enforce?

I find it disturbing that the use of field selection as general function
application is not documented in the language reference manual (it
specifically refers only to selecting fields, not applying functions),
but is being used as some kind of justification for sticking with what
we have at the moment.

I do not remember a general function application mechanism being part of
the original proposal field selection proposal, and just because we got
one for free doesn't mean we are now obliged to keep it.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------