[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reasons for withdrawal

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.

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.
> scgmille@xxxxxxxxxxxxxxxxxx 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.  


Attachment: pgpEEZNbkxi7d.pgp
Description: PGP signature