Heirarchical name space allocation /Trees

[Ross Paterson]

On Thu, Apr 01, 2004 at 04:27:56PM -0500, Dylan Thurston wrote:
> On Thu, Apr 01, 2004 at 03:41:22PM +0200, Christian Maeder wrote:
> > Ross Paterson wrote:
> > >On Thu, Apr 01, 2004 at 01:00:59PM +0200, Christian Maeder wrote:
> > >
> > >>However, I would not mind such a class if it eases other implementions, 
> > >>but from a user's point of view, I want different modules with the same 
> > >>interface (and as few as possible class constraints).
> > 
> > Which "same way"? I'm happy with small and useful classes.
> 
> Perhaps the problem is that the classes proposed so far for sequences
> and other collections have been rather heavy-weight things with a lot
> of members.  Maybe if there were an interface that resisted the
> temptation to throw everything into the class you would be happier?

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.)

A sequence class would probably have at least 30 methods, since many
operations have efficient specializations in at least one implementation.
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.  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.  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.