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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
