[m-dev.] for review: improvements for record syntax

[Ralph Becket]

>From Fergus Henderson on 08/12/2000 05:51:19
> > > > That's why I'm flip-flopping to support policy (2)
> > > > now.  I think there is more to be gained by allowing first-class
values
> > > > on the right of ^ (even if not immediately) than is lost by a
somewhat
> > > > confusing argument order on accessor and setter functions.
> > > 
> > > OK, you've convinced me.
> > 
> > Cool.  Is this a quorum?  Can this feature go into the Rudolph release?
> 
> We discussed this at the Mercury meeting today, and there were no
> objections, so the answer to that is yes.  Simon is also planning to 
> eliminate the function name restriction for `^', i.e. to map
> `Field ^ Var' to `Var(Field)'.
> 
> I'd still like to hear Ralph's opinion, to see if he too is convinced
> by this argument.

So far we have:
policy (1) where X ^ f(Y, Z) is sugar for f(X, Y, Z) and
policy (2) where X ^ f(Y, Z) is sugar for f(Y, Z, X)

The `horridness' associated with (1) is based on a false premise,
namely that
> So `Y = f(A), X ^ Y' means `Y = f(A), Y(X)', i.e. `f(A)(X)' or `f(A, X)',
> not `f(X, A)'.
In the first place, Y = f(A), X ^ Y should expand to f(A)(X), *not* f(A, X).
The `horridness' is that Y = f(A), X ^ Y is now different to X ^ f(A).  But
this is correct, AFAICT.

Consider the following cases:
(a) (X ^ Y) ^ f
(b) X ^ f(Y)
(c) X ^ (Y ^ f)         which is the same as...
(d) F = Y ^ f, X ^ Y    which is the same as...
(e) F = f(Y), X ^ Y

Under policy (1) we get the following expansions:
(a) f(Y(X))
(b) f(X, Y)
(c) f(Y)(X)
(d) f(Y)(X)
(e) f(Y)(X)

Under policy (2) we get
(a) f(Y(X))
(b) f(Y, X)
(c) f(Y)(X)
(d) f(Y)(X)
(e) f(Y)(X)

So, (a), (b) and (c) are all different things.  Policy (2) does *not* 
provide that  `X ^ f(Y)'  =  `F = f(Y), X ^ F'  as is claimed (as far as 
I've understood the discussion).

Given this understanding, plus the `naturalness' of policy (1), plus its
greater ease of use for higher order programming, plus the fact that no
weird typing problems arise, I'm strongly in favour of policy (1) and not
(2).

Indeed, the main argument in favour of policy (2) appears to be that it
better supports first-class RHSs for ^.  However, I still find it hard to
see where (1) falls down on this issue and, more to the point, I'm finding
it hard to come up with convincing examples where this would be a good
thing to do and that require policy (2).

I'm still a bit jet-lagged, though, so I may have got the cart before the
horse...

Ralph

--
Ralph Becket      |      MSR Cambridge      |      rbeck at microsoft.com 
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------