> > > But what type does the selector 'item' have? Phil, Mark and Jeff think:
> > >
> > > item :: Ord a => Tree a -> a
> >
> > This looks correct to me, too.
> >
> > If an order is needed to construct a tree, say a search tree, the very same
> > order is (or may be) needed to select an item, e.g. by searching!
>
> But on the other hand a simple test 'emptyTree' will also have type
> 'Ord a => Tree a -> Bool' instead of just 'Tree a -> Bool' !
> (compare with `null : [a] -> Bool')
Indeed, I would expect the context, Ord a, for every function over Tree a.
(This is not so in the haskell98 report 4.2.1 for the empty set, NilSet,
and the class Eq.)
What is the use of an empty tree or set without context?
An abstract data type should not reveal its realization. An empty tree may
have been created by consecutive insertions and deletions. Nodes may only
be marked "deleted" and a test, emptyTree, may be less simple and may even
require the order from the context to traverse the tree.
The context should be associated with the type constructor and not with the
(value) constructor.
> However, I don't care what Haskell 98 does, because I don't use contexts on data
> type declarations. I think, when writing the interface of an (abstract) data
> type it is an important design decision which operations have which context.
Right, and if you change the implementation, the interface may also change
only due to changed contexts. (A set may be implemented by an unordered
list, such that adding is a simple list-cons, but deleting scans the whole
list and deletes all occurences. Should the context then move from the
constructor to the selector?)
Christian
