'let' keyword optional in do notation?

Hi cafe, For a while now, I've been wondering why the 'let' keyword in a do block isn't optional. So instead of do ... let x = exp1 y = exp2 z <- exp3 ... you could simply write do ... x = exp1 y = exp2 z <- exp3 ... Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with <- bindings, and also makes it less of a hassle to move stuff around. The above probably also holds for list/monad comprehensions, but the explicit let has never really bothered me there. Cheers, Martijn Schrage -- Oblomov Systems (http://www.oblomov.com)

2012/8/8 Martijn Schrage
Hi cafe,
For a while now, I've been wondering why the 'let' keyword in a do block isn't optional. So instead of
do ... let x = exp1 y = exp2 z <- exp3 ...
you could simply write
do ... x = exp1 y = exp2 z <- exp3 ...
Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with <- bindings, and also makes it less of a hassle to move stuff around.
The above probably also holds for list/monad comprehensions, but the explicit let has never really bothered me there.
Hi, This is not a parsing problem, but a scoping one: try to run this program: main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b) Cheers, Thu

Vo Minh Thu
This is not a parsing problem, but a scoping one: try to run this program:
main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b)
Cheers, Thu
Martijn has actually covered this question:
Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with <- bindings, and also makes it less of a hassle to move stuff around.
The suggestion seems sound to me, and the additional 'let' can really be annoying in cases where you have a lot of 'let' bindings among very few monadic actions. My current way to deal with this is to move the stuff to separate computations, but it's certainly not a nice solution: myComp = c >>= f where f x = ... where a = ... b = ... Greets Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad.

On 08-08-12 17:27, Ertugrul Söylemez wrote:
Vo Minh Thu
wrote: This is not a parsing problem, but a scoping one: try to run this program:
main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b)
Cheers, Thu Martijn has actually covered this question:
Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with <- bindings, and also makes it less of a hassle to move stuff around.
To make it more clear, this is the transformation I propose: do ... -- not a let-less binding x1 = exp1 -- \ .. -- only let-less bindings xn = expn -- / ... -- not a let-less binding becomes do ... let x1 = exp1 .. xn = expn ... So main = do x = y y = 5 a = b b = 6 print (x, y, a, b) would put everything in the same binding group and compile successfully. To get Thu's example, you would write main = do x = y y = 5 let a = b let b = 6 print (x, y, a, b) The last let could even be left out. Cheers, Martijn
The suggestion seems sound to me, and the additional 'let' can really be annoying in cases where you have a lot of 'let' bindings among very few monadic actions. My current way to deal with this is to move the stuff to separate computations, but it's certainly not a nice solution:
myComp = c >>= f where f x = ... where a = ... b = ...
Greets Ertugrul
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (3)
-
Ertugrul Söylemez
-
Martijn Schrage
-
Vo Minh Thu