On Thu, 30 Oct 2003 xxxxxx@freenetproject.org wrote:

>On Thu, Oct 30, 2003 at 09:00:46AM -0800, Bradd W. Szonye wrote:

>> But that's not the worst case. Two influential vendors solve the problem
>> in very different and incompatible ways. This annoys library
>> implementors, because they must write two sets of glue code for every
>> library, to accommodate the differences. It also makes it politically
>> impossible to ever standardize the unspecified behavior, because there's
>> no way to do it without alienating a major portion of the users.
>>
>
>So you'd rather we standardize an inferior mechanism now?  By your above
>argument, you can't fix it retroactively through a new SRFI, because it
>will equally annoy users of both vendors who still have to change to
>whatever is standardized in a specification, while in the meantime
>annoying all users by locking them into an inferior dispatch mechanism.
>At least my way doesn't annoy everyone all of the time.

If you standardize on a mechanism now, or at least an interface that
permits new collections to be defined and gives them useful semantics,
then people will write collections.  Heck, I'd wrap up my btree library
and change its argument signatures to make it compatible.

But if I have to wait for implementors to support something natively,
or if I have to write unportable "glue code" to drop it into a system,
then I will not bother -- and in fact I'd be very likely to submit a
different SRFI that specifically obsoleted 44 by creating a portable
interface.

Then the implementers would be happy; they'd have a clear target and
semantics, and if they don't want to do the work for native support
using their implementations' native dispatch mechanism, at least
they'd have usable, efficient, R5RS-portable scheme code that they
could just drop into their systems' libraries.  The library writers
will be happy: they'll have a clear path for creating new collections
and dictionaries that the interface can use.  The users would be happy;
they'd get encapsulated collection types and if some underlying
dispatch mechanism ever gets standardized and the libraries and
collection interface quit using vectors, the users will never know
and they won't have to refactor code. And back to the implementors,
they don't even have to sweat too much about eventual standardization
marginalizing their native dispatch mechanisms, because if that
happens, they can just drop in the reference scheme code.

Concrete implementations are very powerful that way.

				Bear