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, 30 Oct 2003 scgmille@xxxxxxxxxxxxxxxxxx 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