3 ms·
> This is missing a key term: "in scope." True, of course. Sometimes I wish Haskell would have made shadowing variables into a compile error. Shadowing is the
by sfvisser 13y ago
> This is missing a key term: "in scope."
True, of course.
Sometimes I wish Haskell would have made shadowing variables into a compile error. Shadowing is the number one reason that substitution doesn't always work like you expect. (everyone please use -Wall)
However, substitution also doesn't work sometimes because the types aren't polymorphic enough. Let bindings are monomorphic by default nowadays which can give some surprising results.
- quchen 13y agoI guess shadowing produces warnings instead of errors is because sometimes it can be a good thing: you can use it to create the illusion of mutability. In GHC's source I've seen a couple of longer functions (say ~50 lines) that re-use names in let/bind "statements" to get around going from x to x'''; the "x" simply kept shadowing its previous value.
- judk 13y agoNot just prettier, but it is more correct to shadow if your intent is to make the original x unavailable. It would be cleaner/safer if the language had a keyword like 'shadowlet'.
- velis_vel 13y agoI've also done stuff like x <- m1; f x; x <- m 2; f x; in a do-block, and it's not clear to me how to write 'shadowfrom' (or however you pronounce '<-' in that context).
- judk 13y agoMaybe this would be cool: x! <- m 2 Sort of like a strictness annotation. In think it would be a compatible language change, since only identifiers can currently appear left of a <-
- judk 13y agoIt is isn't just shadowing. f1 = let x = 1 in x f2 = let x = 2 in x It would be insane to ban that in the name of "equational reasoning".