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