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

Re: problems with rationale & design

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.