Strict vs Lazy Pattern Matching

This poll is now closed! The results can be found here.

Background

In Haskell, patterns can be matched either strictly (the match is performed immediately) or lazily (the match is deferred until one of the variables it binds is needed). The type of matching depends on the context in which the pattern is used, so for example 
case e of Just x -> f x
evaluates e and matches it against Just x before f is called, while 
let Just x = e in f x
evaluates e and performs the match only if f actually uses x. A pattern can be forced to match lazily by applying the ~ operator to it, so 
case e of ~Just x -> f x
behaves just like the let above. There is no way to force strict matching in a let. Pattern matching has had this meaning since the first version of Haskell.

The Issue

Some of the committee consider that the different behaviour of pattern matching depending on the context is an anomaly; that it makes the language (a bit) harder to learn -- there is more to remember; that it makes strict matching in a let unnecessarily hard to achieve (let must be rewritten as a case). This group believes that a cleaner language design would be for matching to be strict everywhere, except where explicitly indicated using ~. This change would make recursive definitions such as 
let (x,y) = (1,x) in...
non-terminating, because the rhs cannot be evaluated until after x and y are bound, which cannot happen until after the rhs is evaluated... However, a simple compile-time check can detect many such cases.

Changing the meaning of pattern matching would undoubtedly change the behaviour of many programs. Many functions would become a little stricter; some programs would stop working, while others would experience a change of evaluation order leading perhaps to space leaks that didn't exist before. There is no hard evidence that these problems would be severe, but neither is there evidence that they would be insignificant. Another group on the committee (overlapping with the first!) believes that it would be wrong to take the risk.

A smaller group believes that the present design is superior in principle to an `always strict' design. In a lazy language, nothing should be strict unless it must be. ~ is a subtle operator which the programmer should not need to understand. Making matching strict in lets will surprise the lazy programmer and lead to unexpected errors in programs.

However, the views with most support are the first two: that consistently strict matching is a better language design, but should not be adopted because of the pain it would cause existing users.

The Question

It isn't easy for the committee to weigh up the benefit of a simpler language against the `dismay and frustration' that existing users might feel, without asking those people for their opinions. So let us have yours by filling in this form. If you would like to see the (extensive) discussion that the committee has had, you can find it here. If you would like just to read a few messages, look at this in favour of strict matching, this one against, this discussion of an example that would break, and (if you have the stamina) a summary and the most recent discussion.
Last modified: Sun Dec 14 17:30:35 MET 1997