[m-dev.] Freeze the compiler

[Ralph Becket]

>From schachte at cs.mu.OZ.AU on 13/11/2000 12:34:22
> 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.

Okay.  But it's not clear to me why I would want to write

	X ^ foo(A, B, C)

rather than

	foo(A, B, C, X)

(or should that be `foo(X, A, B, C)'?  This seems more natural.)

The current restriction to just naming fields seems reasonable to me.
I fear that taking things further risks confusing the syntax.

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

Sorry, but `Map ^ @Key' is awful!  It's almost worthy of Perl.

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

Agreed - we don't want to do this.  Similarly, we don't want X ++ Y
to be sugar for append(X, Y).  Just having the convention is sufficient.

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

Indeed, I have the patches ready to go for adding infix @/2 to the
language and library.

While it would be nice to be able to write

	X @ I := (X @ I) + 1

I'm not sure it's worth it.  The alternative

	set(X, I, (X @ I) + 1)

is almost as concise.

As for extracting array substrings and array slices, these things occur
sufficiently rarely that, IMHO, specialised syntax is not warranted.

In a nutshell, I think simplicity of syntax is a Good Thing.  We want
just enough magic transformations to make life comfortable and no more.
Of course, I probably have a more ascetic view of `just enough' than
some.

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