
The point of where is that it scopes over guards and multiple equations as well as right hand sides. f x | xsquared < 1000 = xsquared | otherwise = 0 where xsquared = x*x For the same reason, it has to be restricted to appear at the "top level" of a right hand side. Of course, we also need a construct to bind local variables inside an expression -- hence let, which therefore cannot scope over guards. Two kinds of scope, two binding constructions. We could have got away with one, if we had thrown out guards and relied just on if-then-else to test conditions instead. But guards are very expressive: some programs would have been a lot harder to write without them. Typical examples are when we just want to pick out one case in the first equation of a function, before lots of pattern matching: f x y | simplecase x y = simpleanswer f p1 p2 = ... f p3 p4 = ... ... There's no neat way to write this with if-then-else: you need to split f into two functions f x y = if simplecase x y then simpleanswer else f' x y f' p1 p2 = ... ... That's the reason Haskell has two binding constructions. John Hughes

John Hughes wrote:
That's the reason Haskell has two binding constructions.
Its a reason why it was a good decision to have both constructs. There was some debate about which to have - it's a matter of personal preference and style. The problem is that if you have both let and where in the expression syntax, then let a in b where c is ambiguous unless you make an arbitrary decision about the precedence, and that kind of arbitrariness is an opportunity for error - the programmer mis-remembers the rule and gets a syntactically valid program that does not do what was intended. I always though that the resolution, allowing both but making where part of the declaration syntax, thus both having a justification for the parsing order and creating a means to write local definitions which span guarded equations, was a very fine decision. --brian

Thanks very much everyone, especially for the notes about the differences between "let" and "where", and the uses of "case" and "maybe"! Someday it would be interesting to try a programming assignment and comparing my coding style with the useful idioms that everyone else uses to see how much I still have to learn. (-: -- Mark
participants (3)
-
Brian Boutel
-
John Hughes
-
Mark Carroll