That is interesting--I hadn't thought of deriving (Eq) in these terms. Unfortunately it seems that user-defined typeclasses can't use the deriving paradigm. Furthermore, while Functors can be derived in a consistent way, Applicatives can't, which means that deriving isn't strong enough for use in the implicit mapping model I described.
Marshall On Sun, Feb 5, 2012 at 4:07 PM, Boyko Bantchev <boyk...@gmail.com> wrote: > On 5 February 2012 20:04, Marshall Lochbaum <mwlochb...@gmail.com> wrote: > > ... > > I'm not sure what you mean about Haskell's "deriving" descriptor. If I > > understand typeclasses at all, what "deriving" accomplishes is rather > weak > > and not at all related to implicit mapping. > > Here is a typical example. > The following is a datatype describing a binary tree with nodes > of type a. > data Btree a = E | Bt a (Btree a) (Btree a) deriving Eq > It derives from Eq, so trees can be compared for equality by > comparing the values at their nodes pairwise: if t1 and t2 are > trees of, say, integers, then t1==t2 is computed by applying == > pairwise on the nodes of t1 and t2, i.e. by implicitly mapping ==. > If the nodes are themselves trees or other complex structures, > the mapping takes place first at the items of the items, etc. > This is not the usual mapping, as the result of t1==t2 is a single > Boolean rather than a tree of Booleans (a more precise term is > ‘lifting’) but essentially it is (implicit) mapping anyway. > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
