[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 wrote:
>> It seems to me (and to a few other reviewers) that you're building a
>> house on a non-existent foundation. SRFI-44 is allegedly designed
>> with extensibility in mind, but it doesn't actually specify how to
>> extend it. Therefore, each implementor must come up with his own
>> solution, which will become obsolete when (if?) somebody actually
>> publishes the portable extension SRFI.

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're right; there is a huge difference, and planning for
obsolescence is far superior to hoping that everything will go well when
you do want to supersede the original.
Bradd W. Szonye