[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reasons for withdrawal
> 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.
> 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?
Bradd W. Szonye