Email list hosting service & mailing list manager

A liitle note on the side felix (23 Jun 2004 23:44 UTC)
Re: A liitle note on the side Bradd W. Szonye (24 Jun 2004 00:14 UTC)
Re: A liitle note on the side Alex Shinn (24 Jun 2004 03:10 UTC)
Re: A liitle note on the side Bradd W. Szonye (24 Jun 2004 03:55 UTC)
Re: A liitle note on the side Jens Axel Søgaard (24 Jun 2004 05:04 UTC)
Re: A liitle note on the side Bradd W. Szonye (24 Jun 2004 05:07 UTC)
Re: A liitle note on the side Felix Winkelmann (24 Jun 2004 05:19 UTC)
Re: A liitle note on the side campbell@xxxxxx (24 Jun 2004 16:56 UTC)
Re: A liitle note on the side Bradd W. Szonye (24 Jun 2004 18:47 UTC)
Re: A liitle note on the side campbell@xxxxxx (24 Jun 2004 04:19 UTC)
Re: A liitle note on the side Alex Shinn (24 Jun 2004 05:07 UTC)
Re: A liitle note on the side campbell@xxxxxx (24 Jun 2004 01:40 UTC)

Re: A liitle note on the side Bradd W. Szonye 24 Jun 2004 03:55 UTC

Bradd wrote:
>> No, it isn't. Which Schemes already implement REQUIRE-EXTENSION? Any
>> of them? Please, quit trying to pass off a brand new name as "common
>> practice." Extensions that require name changes or new aliases are
>> not "common practice."

Alex Shinn wrote:
> The concept is common practice, and supporting the SRFI can be done
> with a small macro in any Scheme that already supports require.

And because of that, I see it as having little value. It's incompatible
with at least one Scheme implementation, and it doesn't make much sense
for some of the others. For example, PLT Scheme already has a REQUIRE
syntax, with a significant user base, that goes far beyond what SRFI-55
provides. The PLT implementors have a few choices:

1. Change their REQUIRE to REQUIRE-EXTENSION. This would break lots and
   lots of PLT Scheme code.
2. Implement REQUIRE-EXTENSION as a library macro. But then you'd need
   to use REQUIRE to get REQUIRE-EXTENSION, which gives up all the
   portability and terseness of the latter.
3. Implement it as a built-in macro. This introduces a new name into the
   namespace, just to get a feature that's inferior to REQUIRE.
4. Ignore SRFI-55.

Based on the way PLT has implemented SRFI-0 and SRFI-7, I think #2 or #4
are most likely; in either case, it won't see much use. This extension
just doesn't make much sense if you already have a more sophisticated
version of it built into the interpreter.

On its own, this proposal just doesn't have enough value to make it
worth the trouble. Implement it as part of a solid module system, and it
makes more sense. Or as part of an autoconf-like package to smooth over
differences between systems. But in its current, trivial form, it's more
trouble than its worth. And that's even before you consider the scheme48
case. SRFI-7 is more general, more powerful, and elegant enough. A new
proposal along those lines should actually improve on it, rather than
providing a much weaker version that offers nothing but a standard name.

The claims about "saving typing" are especially amusing, given that
it'll take /more/ typing to use it in PLT Scheme than the native REQUIRE
form does. It's only terser compared to SRFI-7, and at great cost.
--
Bradd W. Szonye
http://www.szonye.com/bradd