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