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@pat) to and-patterns (pat@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. Claus