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 http://www.szonye.com/bradd