user-defined operators

[Martin J. Logan]

On Thu, 2004-03-25 at 16:36, Richard A. O'Keefe wrote:
> I'm seeing a certain amount of scaremongering in this thread.
> 
> First, the thread is about user-defined operators, NOT about
> operator overloading.  

They are part in parcel. ad-hoc polymorphism, overloading, user defined
operators are all the same in this context. If the language supports
polymorphic functions then it is reasonable to assume that the addition
of operators based on those very functions would support the same
polymorphic attributes.

> Whatever the merits and pitfalls of
> operating overloading, they are not relevant to the topic of
> user defined operators.
> 
> Second, most functional languages have supported user defined
> operators for years.  ML has them.  Haskell has them.  Clean
> has them.  Prolog has them.  Mercury has them. 

Many of these also include operator overloading(Haskell).
> 
> *DO* you in fact get a welter of confusing operators?
> 
> NO. 

What about this?

It does not seem to me that
>     n `sm` primes
>     seconds `d` 60
>     fromInteger big `aTf` x
>     expr `catch` handler
> are particularly hard to read.

Which I agree is no worse than 

sm(n, primes)
d(seconds, 60)

How about this? 

    N `@#` Primes
    Seconds `@#` 60
    MoreSeconds `@#` (Seconds `@#` String `@#` String2)

I want my `operator` to be defined as such. 

'@#'(A, B) when is_integer(A), is_list(B) -> ...
'@#'(A, B) when is_integer(A), is_integer(B) -> ...
'@#'(A, B) when is_list(A), is_list(B) -> ...
    
I am sure one could come up with some mangled syntax for restricting
this. We could also conjure up a way to define precedence by user
defined precedence number or some such. I am not trying to be polemic
here but it honestly scares me.

Martin

> 
> In part this is because operators can only have one or two arguments,
> while functions and predicates commonly need more.
> 
> Haskell has two kinds of operators: alphabetic ones (which must always
> be enclosed in backquotes) and symbolic ones (which may never be
> enclosed in backquotes).  So in Haskell `elem` is a alphabetic operator
> and `!!` is not legal syntax at all.
> 
> Operators are declared using
> 	infix  [Prec] op...
> 	infixl [Prec] op...
> 	infixr [Prec] op...
> where Prec is a decimal digit.  A symbolic operator may only be used if
> it has been declared.  An alphabetic operator has the weakest precedence
> unless it is explicitly declared.
> 
> Now alphabetic operators (especially if they all have the same precedence,
> as they used to in Haskell) are no harder to read than any other function
> name, and no more subject to overloading.  (Each operator/function in
> Haskell has precisely one meaning in scope.)

> 

> 
> As for the idea that some group of experts should determine a set of
> operators for Erlang, well, (a) they already did, and (b) if the
> experts who designed Haskell came up with gems like $! and :% (actually,
> once you know the rule that a symbolic operator starting with a colon
> must be a constructor, it's not that hard to figure out what :% does),
> what reason is there to expect the Erlang experts to do any better?
> 
> The important thing about !! is not that it is spelled bang-bang, but
> that it is a concise notation for doing a remote procedure call.
> 
> Suppose that alphabetic operators *only* were adopted, so that any
> Erlang user could use any two-argument function as an infix operator.
> Instead of
> 
>     Result = Pid !! Message
> 
> we'd have to write
> 
>     Result = Pid `rpc` Message
> 
> which is three characters longer but 100% clearer.
> 
> I note that Fortran has had user-defined operators for a while now;
> the syntax is <dot><name><dot>, so the Fortran equivalent might be
> 
>     Result = Pid .RPC. Message
> 
> I haven't heard anything about an explosion of unreadability in Fortran
> since this addition was made; maybe using words as operators really isn't
> any worse than using words as function names.