Dan Licata wrote:
Simon PJ and I are implementing view patterns, a way of pattern matching
against abstract datatypes, in GHC. Our design is described here:
http://hackage.haskell.org/trac/ghc/wiki/ViewPatterns
If you have any comments or suggestions about this design, we'd love to
hear them. You can respond to this list (and we can take it to
haskell-cafe if the thread gets long) or, if you prefer, directly to me.
At the risk of being a spoil-sport, I have a somewhat negative take on view
patterns. Not because I think they're particularly bad, but because I
don't think they're significantly useful enough to warrant adding to the
language, at least if we also have pattern guards.
All of the examples on the wiki page can be written in the same number of
lines, sometimes with fewer characters, using pattern guards or some other
existing Haskell idiom (e.g. the bit parsing example is much more nicely
expressed using a bit-parsing monad). I believe adding yet another idiom
will be detrimental: too much choice is bad.
To my eyes, mixing bound and binding occurrences of variables in patterns
in an arbitrarily nested way is sure to lead to confusion. The existing
idioms all have a one-level deep notion of bound/binding scope, and in
order to get more nesting you have to start naming things: this is good,
IMO. Not that I think we should omit a language feature because it *could*
be used to write obfuscated code; no, in this case I think nesting more
than one level deep will *always* lead to obfuscated code.
The use of the right-arrow is confusing, especially on the left of a case
alternative or in a lambda expression.
The main argument in favour of view patterns is:
> it's possible that people would start routinely hiding the data
> representation and exporting view functions instead, which would be an
> excellent thing.
My impression is that most of the time a data structure has a clever
internal representation that you don't want to expose anyway. This is
supported by the data structures we have in the base package, all these are
abstract:
Data.Set, Data.IntSet, Data.Map, Data.IntMap
Data.Graph, Data.Sequence, Data.Bytestring, Data.Array,
Data.HashTable, Data.Ratio(Rational)
and most export view-like things (e.g. Data.Set.toList).
The modules I found that export non-abstract types that should really be
abstract:
Data.Complex, Data.Tree
So I don't think there's an overwhelming amount of stuff that would change
if we had view patterns. In GHC itself most of our data structures are
already abstract too.
The View class is nice, even with just pattern guards. I'd be in favour of
making it standard and actively encouraging its use.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
