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.
At Thu, 30 Oct 2003 02:40:52 -0500, Anton van Straaten wrote: > > Bear wrote: > > SRFI-44 does not need to depend on any OO framework or library to get > > dynamic dispatch based on the collection type. > ... > > Therefore consider as a possibility, a vector a few dozen elements > > long. Let the first element, at index zero, contain a symbol that > ... > > And it'll work. Immediately. And it'll be totally clear to > > everybody how to write collections that this interface can use. > > This could make a nice reference implementation. It's not completely clear > to me whether you're also suggesting that this should be something that the > spec requires of implementations, though. I don't see the need for it in > implementations that already provide a generic dispatch mechanism - it would > only add overhead. Almost insignificant overhead. Such a portable reference implementation should not use vectors, or even assume the underlying data structures, but just use a consistent API for creating types and methods. The reference implementation itself could be written using records, but implementations would be free to define (define-collection-type ...) (define-collection-method ...) in terms of their underlying object system as a later optimization, while still retaining compatibility with future extensions. This is the situation with SRFI-9 records. Many Schemes define records in terms of their internal OO system (or vice verse) and the SRFI-9 records are just syntax with practically zero overhead. Ideally I think inheritable records should be factored out of SRFI-35 and specified clearly in their own SRFI. The idea has been discussed by the RnRS authors before: http://zurich.ai.mit.edu/pipermail/rrrs-authors/1988-June/000922.html Then you could specify a separate generic function SRFI which builds on the inheritable records, and SRFI-44 and future SRFI's could depend on such minimal dispatch without having to go through the nightmare of creating a standard Scheme object system. If you introduce it in pieces like this it's likely that every single Scheme will implement it, but if you tell implementors they must use TinyCLOS they'll get defensive and insist their native OO system is better. -- Alex