[m-dev.] 0.13 release: op/3 syntax

[Jonathan Morgan]

On 3/4/06, Mark Brown <mark at cs.mu.oz.au> wrote:
>
> On 04-Mar-2006, Jonathan Morgan <jonmmorgan at gmail.com> wrote:
> >
> >    I think that something like op/3 might be a useful feature.  I
> >    certainly think that Haskell is far more powerful because of its use
> >    of user-defined operators in the standard library.
> >    Haskell treats operators as functions, meaning that they can be
> >    exported and used in typeclass definitions.  This means that you can
> >    have typeclasses like Ord, Eq and Num that provide operations like
> >    (<), (>), (==), (+) etc., which means that user-defined code can
> >    implement these type-classes, rather than leaving them a black box
> >    available only to the implementors of the compiler
>
> Mercury has those operators, and you can define them however you like.
> Indeed, that's what the int.m and float.m modules do.  You can easily
> define a `num' typeclass in Mercury, but currently the standard library
> doesn't do it that way.


I seem to remember reading something about user-defined equality not working
well with Mercury - but I'm not sure why.  Also, Haskell's way provides
type-class constraints, which you can then use in your function signatures.
Can anything like that be done with Mercury built-in operators?  (For
example, I know C++ can have operators overloaded - but I know of no good
way of making a function work over every class that has re-defined all the
ordering operators, or whatever it might be).

The issue is whether you can make non-operator names into operators in
> your program.  In Haskell, this would be equivalent to writing, say:
>
>         infix 3 member
>
> instead of
>
>         infix 3 `member`
>
> which, as I pointed out a moment ago, Haskell will not accept.


I have no particular objection to the back-ticks syntax - especially if it
is extended to solve precedence and associativity problems.  What I was
saying was that Haskell allows a particular subset of identifiers to be
treated as operators, and I think that the op/3 syntax would benefit from
this, as it would be much easier to identify what is an operator, and what
is not.  I do not like the idea of any arbitrary word being an operator, as
it would lessen the readability of the code, but I do think Haskell's idea
of having (I think) up to five symbols together counted as an operator is
sound.

>    However, Haskell also has limitations on what can qualify as an
> >    operator, meaning that you cannot define arbitrary operators (I think
> >    they need to be all symbols, not just arbitrary words).
>
> That's right.
>
> > This enables
> >    users to clearly distinguish between an infix operator and an infix
> >    function (with back-ticks).  These infix functions can be given
> >    precedences and associativity, which makes them easier to use.
>
> Correction: they can be given a precedence and associativity which differs
> from the default, or from any previous values.


The default will always be the same for infix functions currently though,
won't it?  The real danger is in allowing people to change the precedence of
built-in operators (eg. make (+) higher than (*)), as that would be
confusing.  Should users be allowed to change the precedence of pre-defined
operators at all (or issue any :- op command for an operator that is already
defined)?

I still think that user-defined operators lose most of their use if they
cannot be exported, but I believe exporting them is going to cause more
trouble.

Jon

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurylang.org/archives/developers/attachments/20060305/8d445a68/attachment.html>