Bradd W. Szonye wrote:

> 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."

As Alex Shinn writes, it is common practice to provide the functionality.
The reason for giving it another name makes it possible to let it
coexist peacefully with existing code (at least that's how I see it).

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

5. Implement srfi-55 as a TeachPack, which means that there is no
    visible REQUIRE in order to use REQUIRE-EXTENSION.

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

It makes sense to those users that want their libraries to run in
several Schemes with minimal changes in the source code.

> On its own, this proposal just doesn't have enough value to make it
> worth the trouble.

That argument a srfi is a slippery slope. Was is worth making a
RECEIVE srfi - it's just a single macro?

Since the proposal is here, some found it worth the trouble.

> Implement it as part of a solid module system, and it makes more sense.

True. But what should one do before "R6RS" is finished?

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

No typing is involved in loading a TeachPack - but the typing-argument
is a red herring.

The important part of the proposal is to have a mechanism that works
in as many Schemes as possible and makes it possible to distribute
portable code using srfis without any changes of the source code at all.

--
Jens Axel Søgaard