Original-Via: uk.ac.nsf; Thu, 5 Dec 91 12:13:51 GMT
Original-Sender: [EMAIL PROTECTED]
| I wonder if the following syntax change is not too late for the
| SIGPLAN version of the Report? I actually view this as a FIX to
| something I consider WRONG, since I believe (correct me if I'm wrong!)
| that V1.0 permitted this.
|
| The problem is that V1.1 does not allow things like:
|
| f x $ \y->
| g y $
| ...
|
| where the fixity of $ is defined as:
|
| infixr 0 $
|
| Rather, one must insert parens thusly:
|
| f x $ (\x->
| g x $
| ...)
|
| Writing this kind of code is extremely common when using Haskell's
| continuation-based I/O, monadic programming, cps-based programming,
| etc. Having to insert the parens is a royal pain. By convention,
| lambda abstractions "extend as far to the right as possible", so I
| don't see why we should require the parens. I think this change came
| about when we did the fancy re-write of the syntax to accommodate
| explicit precedence levels. Would anyone object seriously to changing
| things back to the way they were?
|
| -Paul
I agree that the current syntax makes cps, etc., painful, so I would
agree that we should fix it. The current version of the syntax was
intended to make the effect of fixities clear and to sort out the
difficulties about lambdas, ifs, and wheres. Some requirements for
parentheses were deliberately introduced in an attempt to produce a
precedence system that seemed rational. The thing is, a lot of this
trouble was caused by where-expressions, and when we decided to replace
those with let, these decisions should have been reconsidered.
OK. At a minimum, we want to allow a lambda abstraction to be the
right argument of an infix operator without being parenthesized. I don't
see how to do this consistently without going the full route, though:
I would suggest that we go ahead and allow unparenthesized lambda
abstractions, let-expressions, and conditionals at the right of
an application or inifix expression and also make case expressions aexps.
I believe that this would restore the full flexibility we had before
I did the syntax revision, but without the complications caused by
where-expressions. For example, all of the following would be OK:
x $ \x -> x^2 + 3
f \x -> x^2 + 3
x + if a == b then 1 else 2
x + case ys of
[] -> 0
(y:_) -> y
+ z
One may well argue that some of the above are are of questionable style
and might need some parentheses for clarity, but it seems that the example
of the difficulties of cps with the current syntax suggests that restricting
the syntax for such a reason is unwise.
I've considered briefly what would be involved in implementing this
in the context-free syntax (and at the same time fixing the bug that
(- x) is not an expression), and it doesn't look to be too bad without
where-expressions mucking things up. Does everyone agree that this
is what we should do, though?
--Joe
