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

Re: problems with rationale & design



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