[Haskell-cafe] Custom unary operator extension?

[Henning Thielemann]

On Sun, 9 Sep 2007, Peter Verswyvelen wrote:

>> Why? What is your application? In fact, alphanumeric identifiers are used 
>> as unary operators.
> Why? Well, why are binary operators allowed and unary operators not? Isn't 
> that some kind of discrimination? In math, many many operators are unary. 
> Haskell allows creating binary operators. So I would understand that Haskell 
> supported neither binary nor unary operators, but prefering one above the 
> other just seems odd. Especially when coming from C++ and C#.

The more syntactic constructs exist, the more complicated it becomes to 
read such programs. Today, if you read a symbolic operator which is not 
"-", not a single dot with a capital identifier to the left 
(qualification), not a double dot in a bracket (enumeration) and not 
enclosed in parentheses (prefix mode), then it is an infix operator. Note 
the already existing exceptions, and I feel these are not complete. With 
prefix operators it becomes more difficult.

> My application? I'm teaching basic math to beginning video game programmers, 
> and I wanted to demonstrate the logic operators "not, and, or, logical 
> equivalence and implication" etc in Haskell, building them from scratch. 
> Since most programmers have symbol-phobia, I wanted to let them play with the 
> symbols for operators, with Haskell. E.g. \/, /\,  --> <--> ==> <==> for or, 
> and, if/then, iff, logical implication, logical equivalence, etc... I cannot 
> do this for the "not" operator, which is a bit annoying, but it's not a show 
> stopper.
>
>> You can also use "special syntax" for having unary operators. E.g.
>> 
>> (*) :: () -> a -> a
>> 
> Nice trick :-)

Even more simpler is enclosing the symbolic operator in parentheses.

(-|) :: Bool -> Bool

use as    (-|) False

>> I think that the benefits of prefix or postfix symbolic operators were not 
>> worth dispensing with the comfortable section syntax.
> Well, that's personal I guess, but I would prefer the syntax (? / 100) and 
> (100 / ?), which is just a single extra character to type, and hence allow 
> unary operators, but hey, that's just me, the newbie ;-)

It's easy to predict, that people then soon want to write (? * ?), 
disputing whether it shall mean (\x -> x*x) or (\x y -> x*y), and you will 
quickly re-invent lambda notation.

See
  http://www.haskell.org/pipermail/haskell-cafe/2006-July/016683.html

It's tempting to want more syntactic sugar, but there are already so much 
suggestions that I'm afraid, that the resulting language would be as 
ambiguous as a natural language.
  http://www.haskell.org/haskellwiki/Syntactic_sugar/Cons