Earlier on the Haskell' list, I proposed bang patterns as a way to make it more convenient for Haskell programmers to make their programs stricter. E.g. f (!x, y) = .... I've documented the proposal here http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/BangPatter ns I've implemented it in GHC, so you can try it out. Use -fbang-patterns to enable bang patterns. If you use -fglasgow-exts you get -fbang-patterns as well. If you don't want that, use -fglasgow-exts -fno-bang-patterns. I'd be interested to hear your experiences. (Committee members: do add notes to the Wiki page giving pros and cons.) Simon
Simon Peyton-Jones wrote:
http://haskell.galois.com/cgi-bin/haskell-prime/trac.cgi/wiki/BangPatterns
You say that let !(x, Just !y) = <rhs> in <body> can't be desugared to let t = <rhs> x = case t of (x, Just !y) -> x y = case t of (x, Just !y) -> y in t `seq` <body> and I agree. But that's not the desugaring I'd expect; I'd expect this: let t1@(x, Just t2@y) = <rhs> in t1 `seq` t2 `seq` <body> which does have the appropriate semantics, I think. You can also desugar let ![x,y] = e in b to let t1@[x,y] = e in t1 `seq` b instead of case e of { [x,y] -> b }, which would solve the polymorphism problem. The other thing that isn't obvious to me is what should happen when ! is nested inside ~. Naively case e of { (x,~(y,!z)) -> b } should be equivalent to case e of { (x,t1) -> let (y,!z) = t1 in b } which should be equivalent to case e of { (x,t1) -> let (y,t2@z) = t1 in t2 `seq` b } But this is the same as case e of { (x,(y,!z)) -> b } In other words, the ~ has no effect, which is not what I expect. I think there's an incompatibility between the interpretation of ! in let and case expressions. In let expressions it needs to be able to escape from the implicit ~, while in case expressions it should stay inside. One possible solution would be to make top-level ~ significant in let expressions, but that feels a bit strange too. Another minor point: allowing module Foo where !x = ... would mean that adding an import statement to a terminating program could change it into a nonterminating one. -- Ben
Pursuant to a recent conversation with Simon, my previous post to this thread is now obsolete. So please ignore it, and see the updated wiki page instead. -- Ben
participants (2)
-
Ben Rudiak-Gould -
Simon Peyton-Jones