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 09:00:46AM -0800, Bradd W. Szonye wrote: > scgmille@xxxxxxxxxxxxxxxxxx wrote: > > There's a giant difference between obsolecence of a proprietary > > function in Scheme systems and obsoleting an agreed upon standard. > > True. When you plan for obsolescence in an agreed-upon standard, > implementors can assume (or at least hope) that any successors will have > a standard upgrade path from the previous standard. If you leave it > unspecified instead, then each implementor must make his own choices and > worry that future standardization will hedge out those choices, with no > clear upgrade path. > > 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. Scott
Attachment:
pgp8Z3BRmuyDJ.pgp
Description: PGP signature