[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with rationale & design
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.