[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A liitle note on the side

This page is part of the web mail archives of SRFI 55 from before July 7th, 2015. The new archives for SRFI 55 contain all messages, not just those from before July 7th, 2015.

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