[Haskell] Views in Haskell

[Claus Reinke]

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