Re: [ANNOUNCE] SRFI --- A new approach to portable Scheme code

From: Dave Mason <dmason_at_sarg.Ryerson.CA>
Date: Tue, 05 Jan 1999 14:19:38 -0500

>>>>> On Mon, 4 Jan 1999 19:16:28 -0800, "Dave Richards" <dave_at_synergy.org> said:

> There is little incentive for language implementators to maintain
> language compatibility across implementations. The panacea of a
> portable language has never been met after decades of such attempts.
> The LISP vendors share such a small part of the computer language
> market today that value addition is important in differentiating
> their products from their competition. Although, as a developer, I
> would love to see our languages held to a more common framework,
> LISP is a prime example of a language in evolution. Why would the
> language vendors be interesting in cooperating in this effort?

It remains to be seen, but there was *very* widespread support for
something like the SRFI process at the Scheme workshop. The only
Scheme group, that I'm aware of that, which wasn't represented was the
RScheme group, and Donovan has certainly made positive comments since.

If the SRFIs are well defined, well modularized, and popular (we have
about 10 of them pending but we don't want to overwhelm people), then
users will demand of the implementors that they support the process
(at least SRFI-0), and if they won't there are lots of other Scheme
implementations that will, so the users will switch. So I think that
SRFI compliance will be one of those values which will be a
requirement for an implementation to attract users/developers.

Finally, most SRFIs will contain a portable (see SRFI-1), or almost
portable (see SRFI-0 and SRFI-2), implementation. And *all* of the
remainder will contain a clear description of how to implement. And
if some vendor has a feature that you want, you can specify it
carefully, include an implementation and submit it as a SRFI. Once it
exists then any other vendor (or ``implementor'' as I prefer to think
of them) can implement the SRFI and be *better* than the original
system because they'll have implemented one more SRFI (at least until
the original implementor provides their implementation in that form).
In actual fact, the original implementor is likely to submit the
feature as a SRFI because once it became a SRFI, they would have a
high-quality implementation before anyone else.

Ultimately, it's up to you, me, and the rest of the users/developers
to *require* the implementors to make SRFIs work.

../Dave
Received on Tue Jan 05 1999 - 20:22:34 CET