Who doesn't get at least a bit uneasy when looking at all the redundancy, in e.g. Edison's code? Okasaki has written some generic functions, but they have to be renamed manually in each module. All for the sake of efficiency! Bertrand Meyer did not propose to handle this via inheritance without ensuring that the compiler would eliminate all the indirections. And that was in 1985!
I may be misunderstanding what you are saying here, but I think you are complaining that Edison has a lot of redundancy because it doesn't use default definitions. And I think you are attributing that avoidance of default definitions to a concern about avoiding indirections. But indirections and "efficiency" (in the sense I think you mean) have nothing to do with it! The redundancy you are referring to comes from two sources. First is the desire for Edison to support *both* the class-based style and the module-based style of accessing the data structures. As other posts in this thread have shown, both styles have their strong supporters, and I didn't see any reason that the library should dictate one style over the other. Because the module-based style doesn't support inheritance, you have to put in explicit definitions for every operation, even if many of those definitions are one-liners that refer to generic functions. The second source of redundancy is that default definitions are largely useless for this kind of library. The problem is that there is rarely *one* generic function that makes sense as the default. Instead, there are often two or three or more functions that are all equally good candidates to be the default. So which one do you choose? If there is one that is appropriate, say, 80% of the time, then sure go ahead and make that one the default. But if there are three, and each is appropriate about 33% of the time, then I think it is more clear not to have a default, and have every implementation state explicitly which of the "defaults" it is using. -- Chris