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 <xxxxxx@ccs.neu.edu>
>    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