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.