Bang patterns, ~ patterns, and lazy let

[John Hughes]

I just looked at the bang pattern proposal in more detail. To summarise:

* Pattern-matching is presently strict against constructors, lazy 
against variables.
* ~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.

John