On Thu, Oct 30, 2003 at 06:25:53AM -0800, Bradd W. Szonye wrote:
> > Bradd W. Szonye wrote:
> >> But leaving it unspecified also limits implementation strategies for
> >> collection authors, just in a different way. Every collection author
> >> will still need to deal with the fundamental limits imposed by the local
> >> SRFI-44 implementation, with the added disadvantage that he can't count
> >> on it being portable to other implementations.
>
> xxxxxx@freenetproject.org wrote:
> > It would be 90% portable.  The major effort in writing a collection is
> > writing the concrete operators and the underlying representation.
> > Adding the collection to a dispatch mechanism is relatively easy, and
> > consists of a number of expressions like
> >
> > (add-method (bag-contains? <my-collection>) my-concrete-bag-contains?)
> >
> > Its just not worth the trade off of fundamentally limiting this
> > without an efficient, pervasive dispatch system just to save a few
> > lines of code per implementation that aren't difficult (monotonous,
> > yes, but not diffiuclt) to write.
>
> Why not specify the interface for doing it, and leave it up to the
> SRFI-44 core implementor to provide the hooking-up code? Would that
> constrain implementations too much?

It may be impossible to specify all the hooking up code.  In particular
defining the type or class and binding the representation to it is going
to be very difficult.  You may not be able to pass any value or function
to the 'define-type' interface that makes any sense.

	Scott