<div>On 3/4/06, Mark Brown <<a href="mailto:mark@cs.mu.oz.au">mark@cs.mu.oz.au</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On 04-Mar-2006, Jonathan Morgan <<a href="mailto:jonmmorgan@gmail.com">jonmmorgan@gmail.com</a>> 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.</blockquote><div> 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). </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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.</blockquote><div> 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. </div> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> 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.</blockquote><div> 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 </div></div>