This page is part of the web mail archives of SRFI 44 from before July 7th, 2015. The new archives for SRFI 44 contain all messages, not just those from before July 7th, 2015.
I've been thinking about this; yesterday I quit brooding about how much the situation annoys me and started trying to think constructively. So... I've got a suggestion. I'm going to propose a change that might meet your goals here without running afoul of the issues that seem to be making problems. I do dispatch and OO programming all the time in scheme, and I don't use any of the popular "OO" frameworks because it's so simple to do OO programming that there's really no need for them. SRFI-44 does not need to depend on any OO framework or library to get dynamic dispatch based on the collection type. If it is desired to have a "generic" interface that can work on collections yet to be defined, then we have to specify how those collections can assume a form that will make sense to that interface. And that doesn't necessarily mean function names, it just means ways to find the functions themselves programmatically. In scheme, that's easy; we can store functions in local variables or structures, just like anything else. Therefore consider as a possibility, a vector a few dozen elements long. Let the first element, at index zero, contain a symbol that gives the type of the collection. Let the element at index 1 contain a pointer to the actual data of the collection, whether it's a hash table or a btree or an association list or whatever. Let the element at index 2 contain whichever procedure can be used to insert! an element into the collection. Then you have the possibility of a generic interface for collections of the form, (define coll-insert! (lambda (coll addition) ((vector-ref coll 2)(vector-ref coll 1) addition))) (define coll-type (lambda (coll) (vector-ref coll 0))) and so on... You wouldn't really write raw index numbers; this would happen inside a let-syntax that associated nice symbolic names with index numbers to simplify maintenance. And any future collection author, if they provide the same vector of functions and the same initial pointer to the data structure, can provide a collection that uses coll-insert! and coll-type. This wipes out your name and argument conflicts; you don't need individual names for all the functions on all the collection types, you just need a few dozen names, all of the form "coll-*" or "dict-*", that nobody else is using. Future collection and dictionary authors will need to use one name only, a name of the form "make-*-collection" or "make-*-dictionary," that returns a collection or dictionary "object" (which is just a vector of data and functions). The mechanism is extensible; you may develop only 20-30 "generic" functions and then let future SRFI authors add more as needs are discovered. For performance reasons, let there always be a constant vector index at compile time, so the function lookups can always be O(1) - even inlined if the compiler is smart - and then maybe bitgrinders like me won't be too disgusted with its efficiency to use it. This avoids type-checking overhead for sequential checks against various collection types entirely, replacing all of them with a single O(1) vector lookup. The mechanism allows default implementations for "efficiency" functions (functions that can be implemented more efficiently on some structures than your generic few operators allow): They can be coded using the generic operators and provided by a make-collection function. Then the implementor of, say, make-olist-collection will start with the vector returned from make-collection and, if she doesn't override whichever functions are profoundly stupid for olists, then she "inherits" generic versions of them from the collection SRFI that will work anyway, however slowly. In fact he could just copy the minimal form he gets back from make-collection into a longer vector and define a few new "coll-*" or "dict-*" functions himself if there wasn't any place for his new stuff in the vector you defined. It becomes the responsibility of the implementors of future collections to provide at least the few generic functions that will make the "generics" work, but they could still override any stupidities in a very well-defined way without breaking the structure of the collection interface. And it'll work. Immediately. And it'll be totally clear to everybody how to write collections that this interface can use. Bear