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.
campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
Yor argument looks somewhat artifical: by proposing a feature that Scheme48 can not implement you accuse me of "alienating certain implementations", but on my reply that this implementation may choose to ignore SRFI-55, you accuse me of trying to "fracture" the Scheme community. Yet, this very implementation (Scheme48) chooses to ignore SRFI-0, thus doing exactly that ("fracturing").I can't do anything about SRFI 0, Felix, and Feeley, as far as I know, ignored the last few arguments that were made against an embedded COND-EXPAND on the SRFI 0 discussion! The only option for Scheme48 in the SRFI 0 case is to ignore it, but since SRFI 55 is not yet set in stone, I can still argue against it and attempt to change it. SRFIs 0 & 55 _force_ the fracturing: Scheme48 _can't_help_it_; all it _can_ do is ignore them. You're trying to accuse Scheme48 of fracturing itself, but _you_ are in fact creating the fracture!
I'm not trying to accuse Scheme48 of anything, I just wanted to show that the argument of "fracturing" that you brought up can be applied to Scheme48 (or better, the authors of SRFI-7) just as well. Remember, it's you who started the whole "fracturing" issue.
SRFI 0 was already in existence, and I believe it was finalized, by the time SRFI 7 was submitted. SRFI 0 worked with many implementations, and those implementors who didn't read the discussion archives probably found SRFI 7 to be unnecessarily repetitive, _ignoring_ the problems it causes with all module systems that have a certain property.
Sure, they are all blind and ignorant. Unfortunately the Scheme community hasn't more of those bright, foresighted people like you.
You forget that implementations have a choice. They may choose to implement SRFI-7 or SRFI-55, according to whatever they prefer. It's you who claims to know The Right Way, and who apparently wants to make that choice for others.I'm not claiming, and I don't think I have in this discussion claimed -- aside from mentioning what advantages Scheme48 can gain --, that a separate configuration language is inherently better.
Of course you did.
But it _does_
permit _not only_ module systems that use a separate configuration
language but _also_ module systems that embed module data into Scheme
code. REQUIRE does _not_ permit both. So, to elaborate on the choice:
- For implementations that use a separate configuration language,
there is _only_one_choice_: SRFI 7, or some other configuration
language (like the one I pointed out on c.l.scheme recently).
Fine, let them use SRFI-7.
- For implementations that embed module data into Scheme code, they
can either use SRFI 7 _or_ a REQUIRE mechanism.
Great, the majority uses a REQUIRE mechanism. To increase portability, SRFI-55 proposes a common mechanism for this.
If you continue with a REQUIRE-like mechanism, the implementations that depend on a separate configuration language are _FORCED_ not to support the SRFI, but the implementations that already support such a mechanism would feel _ENCOURAGED_ to support SRFI 55. That is a _very_clear_fracture that should _not_be_there_.
No, the "fracture" is already there: currently we have SRFI-7 (supported by very few implementations) and various REQUIRE-like mechanisms. By standardizing the latter, we can make it at least a little bit easier to write portably code for the majority of Scheme implementations.
In this situation, _YOU_ are making the choice for all these implementations, and the choice will cause a _fracture_!
No, you don't understand.
(Remember, though: for all those little quick scripts you write, you can _still_ use REQUIRE, because your implementation supports it, and portability doesn't matter there! Indeed, if I wanted to save those keystrokes while using scsh, I'd use the -o option on the scsh command line, which is _even_more_concise_ than REQUIRE!)
But that wouldn't be portable across multiple implementations. Anyway, you haven't convinced me, and by repeating it endlessly and by abusing your "_" key, you will not convince me in future. So I recommend you change your strategy or simple accept that you can't do anything about it, unless you try something new. cheers, felix