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 ([EMAIL PROTECTED]) to and-patterns
([EMAIL PROTECTED])
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
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
