Malcolm:
Me too. It is a nice observation of a particular point in the design space, but it is so similar to pattern guards that I would not want to have both in the language. Pattern guards win for me, because there is no implicit Maybe, and computation sharing is explicit.
pattern guards and view patterns are incremental steps on the way from simple patterns to more general ones, from concrete constructors and patterns to abstract ones. I doubt either of them is the final word, so it seems to make sense to have several overlapping intermediate stages available while we figure out what works and what doesn't. At least, I'd give such an incremental, informed-by-practice approach better chances of success than the various paper-only complete redesigns we've seen (or not) in the past. I'm always in two minds about whether or not to use pattern guards, but with view patterns added to the picture, I'd have to do two levels of translation to make do without them (view patterns to pattern guards, pattern guards to MonadPlus). and pattern guards do have an implicit Maybe, just that the embedding/ return/Just is also implicit.. without something at least as structured as Maybe, pattern match failure could only give rise to exceptions. perhaps you are mostly thinking of flat patterns, where the pain of adding explicit Maybes wouldn't be as great as for nested abstract patterns? Philippa:
I'm tempted to suggest this may be akin to issues like let vs where or patterns in bindings vs explicit lambdas - examples where having both adds human-expressibility to the language.
instead of let vs where, I think the situation is more like declarative vs imperative construction of data structures. Imagine some abstract binary list type with cons/nil constructors and consP/nilP pattern functions: - construction (declarative vs imperative) cons 1 (cons 2 nil) vs do { x <- mkNil; y <- mkCons 2 x; z <- mkCons 1 y; return z } - deconstruction/matching (view patterns vs pattern guards) f (consP -> (1, consP -> (2, nilP) )) = True vs f z | (1,y) <- consP z, (2,x) <- consP l, nilP x = True I prefer the nested versions over the linearized ones.. and while pattern guards are easy to replace, the combination of nesting and variable binding is difficult to achieve without syntactic sugar. so my intuition tells me that view patterns are a step in the right direction. as a guess, use of pattern guards will decline, but remain for matching tasks that involve multiple parameters (one could simulate pattern guards via view patterns and extra parameters, but that seems awkward;-). Claus