[Haskell] Views in Haskell

Claus Reinke claus.reinke at talk21.com
Mon Jan 29 07:15:26 EST 2007

>>    mapA f (nilAP -> ()) = nilA
>>    mapA f (consAP -> (h,t)) = consA (f h) (mapA f t)
>>    foldA  f n (nilAP     -> ())    = n
>>    foldA  f n (consAP -> (h,t)) = f h (foldA f n t)

yes, maps and folds are likely to be parts of the ADT interface, rather than
defined on top of it. I just used them as simple and familiar examples, so
that we have something to compare them with. 
> To me this exactly illustrates why view patterns are a bad idea: 

whether or not an ADT interface is well designed, according to some metric, 
does not tell us whether or not the language features used in the code are 
good or not. hiding the internal representation always raises questions of
whether the exposed interface is still expressive enough or allows efficient 
code to be written, even without view patterns. 

in other words, ADTs do not only conflict with the ease of pattern matching, 
but also with other possible advantages of using the internal representation 
directly. view patterns help to address the convenience/readability issue, but
the other issues remain to be addressed by careful interface design.

in this particular case, I believe that separate compilation is the main 
concern standing in the way of optimizing the abstract view away.


> you've taken some concrete type, abstracted it to replace the actual structure 
> by a list structure, then defined map and fold over the list structure. This 
> means that map and fold can't take advantage of the actual concrete 
> structure and are therefore condemned to use the inefficient linear 
> structure imposed by the list abstraction.
> For example implementing map over a tree directly, gives the possibility of 
> parallel execution since different subtrees can be mapped independently. But 
> when you view the tree abstractly as a list, no such parallel execution can 
> take place. Therefore surely it is better that map and fold are defined for 
> each ADT separately, with the separate definitions hidden behind a type 
> class, than to attempt to define them "outside" the definition of the ADT 
> using view patterns?
> Brian.
> -- 
> http://www.metamilk.com 

More information about the Haskell-prime mailing list