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