[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.

> 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?
Bradd W. Szonye