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.
Claus
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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
