[Haskell] Views in Haskell

Claus Reinke claus.reinke at talk21.com
Tue Jan 30 08:39:10 EST 2007

> Below are some comments on the goodness of view patterns in relation
> to Palao's active patterns, and especially to their "@" combinator.

The generalization of "@" from as-patterns (var at pat) to and-patterns (pat at pat)
seems to be a useful step, especially in combination with using views mostly as 
observers/selectors - for instance, if views for record selections were defined, 
one would want to be able to match against/observe several fields without
having to match against all of them.

The wiki page has a definition of an "@" combinator that works in the 
pattern functions/data parsing framework, and can be used with view
patterns. I don't find it all that clumsy, but it does highlight a limitation of
view patterns (view -> pat): they are not first-class entities. The view parts 
are, and can be composed dynamically (that is what the "@" combinator 
given there does), but the pattern parts are not, so their composition has 
to be constructed statically.

> A few people have replied that there's not a lot of "pattern matching" in view
> patterns. In (expr -> pat), pattern matching occurs in the observer function
> expr and, when it returns a Just w value, w is matched against pat. But in
> most cases w is a single value or a tuple of values. In the extension with
> JustN (N=1..?), w is often just a list of variables, not much of a pattern.

I have seen several votes against JustN, none in favour. And if many examples
only have a tuple of variables in the pattern part, that is a case of non-exhaustive
examples, not a characteristic of view patterns. I was misled by this, too, at
first, which is why I have tried to emphasize the value of nested view patterns
since. view pattern can be used as observers, in which case the pattern merely
binds the observation results to variables, but they can also be used as
transformers, in which case the pattern describes a full match of a transformed
parameter (or of its subexpressions). in both cases, nested view patterns are 
likely to arise in practice.

Also, there are at least two fractions, one which would like the expr part of 
view patterns to be nothing but a transformation, with all matching limited to 
the pattern part, and one which would like the expr part to describe a pattern
function with possible match failure, with the pattern part limited to describing
matches and variable bindings for the subexpressions (I am in this latter camp;-).
> Of course, this is so because view patterns are syntactic sugar for
> observation, that is, optional discrimination (guard) followed by selection of
> values that are bound to variables. The "failure" case is hidden and nested
> observation can be expressed more neatly. In other words,
>  expr -> pat    ...   [discriminate + ] select -> variables

while view pattern can be used in this mode, the more general form seems to be:

    [discriminate abstract constructor +] extract subexpressions -> match subexpressions

(more general because the observation form simply ignores some subexpressions
and often needs no further matching on the rest)

> One problem with this is that discrimination may take place multiple times and
> selections may be discarded after matching, and both operations could involve
> elaborate computations. 

repeated discrimination arises because pattern functions tend to define refutable
patterns, and the compiler may not be able to determine mutual exclusion when 
the discriminators involve arbitrary boolean expressions. it is, however, quite 
possible to define pattern functions for irrefutable patterns (no discrimination,
only selection) - it would just be up to the programmer to use them wisely..
(ie, irrefutable split *after* refutable empty, but not vice-versa).

discarding selections or, more generally, common computations, before going
to repeat them in the next match alternative, is a different issue, already mentioned 
on the wiki page. I suspect it can be dealt with be restructuring the code to expose
the sharing, but I am not sure yet about whether that would be so detrimental
to readability as to negate the advantages of using view patterns in such cases.


More information about the Haskell mailing list