Heirarchical name space allocation /Trees

[Christian Maeder]

Ross Paterson wrote:
> Let's consider only sequences, since the others require constraints on the
> values stored, multi-parameter type classes and functional dependencies.
> (We're talking about the design of a data structures library we can
> start to use soon, which rules out such fancy classes, at least in the
> core interface.)

ok.

> A sequence class would probably have at least 30 methods, since many
> operations have efficient specializations in at least one implementation.

How much existing code would break, if all our current list functions 
(from Prelude and List) would get the additional context "Sequence" 
(given we wanted to keep the current names)?

> But almost all of these would have default definitions, so new instances
> could be defined economically.  Many operations parameterized on sequences
> could be defined outside the class.  

This somehow splits the interface into some class members and other 
functions.

> Given that, I don't see why the
> size of the class is a problem.  In particular I don't see why a large
> common interface is better handled by trying to use the module system to
> do overloading.  

I don't want to do overloading with modules, just pick a single (most 
appropriate) list implementation for my current task.

> That approach certainly leads to a lot of duplicated
> code (the default definitions and the parameterized functions, e.g. N
> copies of sum = reduce (+) 0).  This is what classes are good for.

How many implemenations to you want? Eventually I suspect about 3 
implemenations to be useful.

I don't know if the size of a class matters, but some code duplication 
could be avoided by a minimal class (empty, isEmpty, cons, head, tail) 
as well.

Christian