[Haskell-cafe] Re: [Haskell] View patterns in GHC: Request for feedback

[Simon Marlow]

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