Original-Via: uk.ac.nsf; Tue, 5 Nov 91 02:56:42 GMT
Original-Sender: [EMAIL PROTECTED]
Tony writes:
It has been pointed out to me by the Yale implementers
that the expression a*b/c causes a parse error because / is infix
rather than infixl and is of the same precedence (7) as * which IS
infixl.
Is this an oversight of someone on the committee or are Haskell arithmetic
expressions different from those of most other languages on purpose? If so
what was the purpose?
The purpose was to remove a possible source of error, in the same way that
expression syntax was changed to replace "where" by "let".
"if a then b else c where d" is ambiguous, so the definition had to make
an arbitrary rule to resolve the ambiguity. Arbitrary rules are bad - I
can't remember which parsing was specified for this example, so I could
easily write code based on an incorrect assumption, and so could someone
writing critical code for the space-shuttle. In this case it is better to
avoid having such constructs in the language, hence "let d in if a then b
else c", or "if a then b else let d in c", which are not ambiguous.
Arithmetic operator expressions are a bad case of this, because everybody
KNOWS what parsing is universally accepted - they were taught it in school.
The problem is that not everyone actually agrees what the universally
accepted parsing is! We had a big debate over unary (-). Those of us with
C/Algol68 upbringings assumed it had a higher precedence than any infix
operator. The Fortran/Pascal/most-other-languages people said not. In this
case we changed the language, but didn't solve the problem.
The annoying thing about a*b/c is that, for well-behaved types, both parses
imply the same value, so there is no problem. But what about a/b*c, and
a/b/c ? And if we insist that (/) is infixl, should the Integral equivalent
operator `div` also be infixl? Did we learn in school how to parse
a*b`div`c?
For new operators, where people know there is no universal convention, and
look up the precedence/associativity before using them, there is little
risk. For cases where there really are universal rules, like for a+b*c,
the language conforms, but where there is a reasonable chance that a
programmer could make a wrong assumption, it's best to require the
parentheses. Write (a*b)/c or a*(b/c) to make your intentions clear.
--brian
