[m-dev.] Freeze the compiler

[schachte at cs.mu.OZ.AU]

On 13 Nov, Ralph Becket wrote:

> Fair enough, although it seems orthogonal to me.  As I understand it,
> the idea is to generalise from `X ^ Y' --> `Y(X)' to also handle
> curried stuff, `X ^ Y(A, B, C)' --> `Y(A, B, C, X)' (+ `:=' case).

Yup.  That was the original proposal.

> 1. How would such syntax be declared?

I'm not sure it really needs to.  You could just treat '^' as an infix
reverse-order version of call/2.  Perhaps add the restriction that the
principal functor of the second argument must be known at compile-time. 
I don't see any strong need for another declaration.

If it is decided there should be a declaration, I'd argue that it
should be separate from the type declaration, for the same reason that
instance declarations are.  Sometimes it would be nice to add accessors
for a type someone else defined without bothering to add the accessors
you want.  I also think it should not be required to define a setter for
every accessor.  It's occasionally useful to have read only accessors. 
And of course, it's important to be able to export accessors and
setters.  All of this is easy if you don't require a special
declaration, and it's all at least a bit of a nuisance to implement if
you do.

> 2. Would it also work for, e.g., typeclass methods (that is, is this
> just a syntactic transformation.)

It should.

> Either way, lookup op's are very common and adopting the concise `@'
> convention doesn't seem like too much hassle.
> 
> On the page, we get the following:
> 
> 	lookup(Map, Key)
> 	Map ^ lookup(Key)
> 	Map @ Key

I wouldn't write "Map ^ lookup(Key)", as that doesn't really make
sense.  You're not fetching lookup(Key) of Map.  I think "Map ^
element(Key)" or maybe "Map ^ elt(Key)" makes more sense and reads
better.  Even "Map ^ @Key" would be OK.

I suppose you could then add the transformation that "X @ Y" ==> 
"X ^ element(Y)".  That should always make sense for any indexable
aggregate type.  I'd argue against it, though, on the grounds that it
doesn't really buy you enough in enough cases to be worth the
complexity added to the language.

The approach you'd probably prefer would be to just make '@' an infix
operator (I have no problem with that), and then add an '@'/2 function
to a few library modules.  My argument against that is that although
it's low impact, it doesn't generalize very well.  (1) It would be
difficult to generalize the ':=' syntax to work with @ (at least I
don't see how); and (2) the '@' syntax is really only good for indexing
strings, arrays, and maps, and maybe a few other finite function-like
types I can't think of now, while the ^ syntax generalized to compound
second arguments can do more, like substrings and array slices.


-- 
Peter Schachte                     The use of COBOL cripples the mind; its
mailto:schachte at cs.mu.OZ.AU        teaching should, therefore, be regarded
http://www.cs.mu.oz.au/~schachte/  as a criminal offense.
PGP: finger schachte at 128.250.37.3      -- E. W. Dijkstra 

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