[m-dev.] user-defined operators

[Peter Ross]

On 09-Jul-1999, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 09-Jul-1999, Peter Ross <petdr at cs.mu.OZ.AU> wrote:
> > 
> > Would the haskell approach taken from the haskell-98 report be an
> > acceptable compromise?
> > 
> > Alphanumeric operators are formed by enclosing an identifier between
> > grave accents (backquotes). Any variable or constructor may
> > be used as an operator in this way. If fun is an identifier (either
> > variable or constructor), then an expression of the form fun x y is
> > equivalent to x `fun`y. If no fixity declaration is given for `fun` then
> > it defaults to highest precedence and left associativity
> > 
> > http::/www.cs.mu.oz.au/~fjh/haskell/haskell98-report-html/exps.html#sect3.2
> 
> I think this is an excellent suggestion.  This would be very simple to
> implement, and would add very little complexity to language.  It would give
> you much of the benefit of user-defined operators while having basically none
> of the drawbacks.
> 
> The main drawbacks of user-defined operators are
> 	- they interact badly with the module system
> 	- they're difficult to implement
> 	- they can potentially make it difficult for human readers to
> 	  parse the code
> 
> In contrast, using backquotes for infix operators with a fixed precedence
> and associativity has no bad interactions with the module system,
> is very easy to implement, and since the precedence and associativity
> are fixed, it should be pretty easy for human readers to parse.
> 
> This is simple enough and useful enough that I think it would be worth having
> even if we were to go on and allow Prolog-style user-defined operators.
> 
The only problem with this approach is that we still can't make the
compose function an operator.

I guess what we need is something like

{f1 `compose` f2 X}

and we collect arguments all the way up to final curly brace to get
the transformed

compose(f1, f2, X)

Another approach could be to allow functional style syntax while in a
functional context.  This is probably the best way to go, but a lot more
difficult to implement.

Any other ideas?

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