This page is part of the web mail archives of SRFI 15 from before July 7th, 2015. The new archives for SRFI 15 contain all messages, not just those from before July 7th, 2015.
Olin writes: >Lars has made the response that he's not trying to use this SRFI to >come up with a "standard" for dynamic binding; he's just trying to >codify existing practice: > > From: Lars Thomas Hansen <lth@xxxxxxxxxxx> > All of these objections are reasonable, but they do not speak to the > purpose of this particular SRFI. The purpose of the SRFI is only to > codify an already existing practice that has slight variations across > implementations (namely, some protect the bindings with DYNAMIC-WIND and > some don't). I submitted it because I find myself using FLUID-LET in > some of my programs, because it is a convenient mechanism for > temporarily and reliably overriding the values of global variables. > >This seems like a waste of a SRFI to me. To each his own. I guess the editors felt differently. > (More generally, I do not think that the SRFI process is useful only for > designing new stuff; it is useful also for collecting old stuff that is > known to be useful, even in limited contexts.) > >In that case, we could take every incompatible R5RS extension of every >Scheme implementation out there and make it a SRFI? Doesn't seem like >a good thing to me. Even though you may not care for FLUID-LET, there are already plenty of Scheme systems that have it, most of them with exactly the meaning I specified in the SRFI. This is not a case of taking "every incompatible R5RS extension" and turning it into an SRFI but to take a widely implemented extension, giving it a name (SRFI-15) and saying that any implementation that claims to support SRFI-15 should have these semantics for FLUID-LET. Other cases in point are CASE-LAMBDA and the string ports (SRFI 6). Not all implementations have these, and in the case of string ports, not all implementations do it exactly that way. But there are several implementations of both features as they are specified. A system that already has SRFI 6 string ports can say it supports SRFI 6, at virtually zero cost to the implementor and the system, allowing the rest of us to write programs that are portable across systems that support SRFI 6. I don't know in what sense this isn't a good thing. No doubt there are other common extensions that could likewise be codified, and I for one would welcome such codification. Designing new and useful features is great, but making it easy to use existing features is just as valuable. >I'd rather use the SRFI process to get people to >come to as wide a consensus as possible on the Right Thing, so that >the SRFI record becomes a growing spec of agreed-upon design. I'm always happy to look for the Right Thing, but (a) I don't usually expect to find it, because different programs and programmers have different needs, and sometimes multiple incompatible designs are better than compromise, (b) the Right Thing tends to change over time, and (c) in the mean time, I'd like to crank out some portable programs that are useful even if they are built upon the Wrong Thing. --lars