xxxxxx@autodrip.bloodandcoffee.net 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