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)
|
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