Bang patterns, ~ patterns, and lazy let
rjmh at cs.chalmers.se
Tue Feb 7 03:02:36 EST 2006
I just looked at the bang pattern proposal in more detail. To summarise:
* Pattern-matching is presently strict against constructors, lazy
* ~p matches p lazily; matching always succeeds, binding the variables
in p to _|_ if matching p fails.
* !p matches p strictly; matching always loops if the value matched is
_|_, even if p is a variable or ~ pattern.
Note that !~p is not the same as p (matching it can never fail, p itself
is not matched strictly), but ~!p is the same as ~p.
So far, so good--everything has a clean semantics and is easy to
understand. Now for the warts:
* Patterns on the left hand side of a let or where are implicitly
preceded by ~, making matching in these contexts lazy by default.
* ! on the left hand side of a let or where *has a different meaning to
! in a pattern* -- it means that the ~ that would have been implicitly
inserted by the previous rule, is not inserted after all! This is not
the same as banging the pattern with the implicit ~, because as I
remarked above, !~p is not the same as p.
This really, really smacks of committee design, doesn't it? Come on,
it's a dog's breakfast! I've made clear before that I consider the FIRST
rule above (that matching in let and where has an implicit ~) to be a
wart already, but giving ! a second meaning to control whether or not
the first wart is really applied is growing warts on warts!
The one good thing to be said for this design is that it doesn't break
existing code. But really--the design is unreasonably complex, and would
just store up trouble for the future. Imagine trying to make a further
extension to pattern matching next time Haskell is revised, without
breaking code that relies on the warts on warts above!
I would urge that either we stick with the present design, or, if bang
patterns are added (which a lot speaks for), that the language be
simplified at the same time so that patterns are matched in the same way
everywhere, and BOTH warts above are excised. Some existing code would
break, but in return the language would become simpler and more expressive.
More information about the Haskell-prime