On Wed, 23 Jun 2004, felix wrote:

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

No, that's simply _untrue_, because SRFI 7, _inherent_ in its design,
can _mend_ the fracture; it _would_, if there weren't people like you
sitting in the middle of the fracture, pushing it apart, and refusing
to budge from your position.  SRFI 7 _can_ work with module systems
that use a separate configuration language, while SRFI 55 _cannot_.
SRFI 7 can _also_ work in _your_ Scheme system -- indeed, as well as
any that embeds module data into Scheme code --, but you _reject_ it
and try to push that fracture wider with your own system.  Then you try
to reverse the argument, which demonstrates that either you don't
understand it -- SRFI 7 _inherently_ supports more module systems than
SRFI 55, but the converse is _not_true_ --, or you're just out of ideas
for ways to argue back against me.

> > 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.

Please.  I was _not_ claiming that I'm a prophet and they're the mass
of ignorance scrounging in the streets.  Rather, 'they' simply have no
reason to consider the module systems whose module systems _do_ use a
separate configuration language.

> > 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.

Quote me.  By 'a separate configuration language is inherently better,'
I refer specifically to the native module system in a Scheme, by the
way, not what can be standardized.  But that ought to have been clear
from the text following that.

> >                                                        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).
> >
> >   - 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.

To increase portability _beyond_ what _just_you_ care about, you could
use SRFI 7 and not bother with a new SRFI!  (Except to amend SRFI 7 to
discuss loading features' code, if you really find that necessary.)
SRFI 7 is an _even_more_common_ mechanism than what SRFI 55 defines.
SRFI 7 _already_supports_ those implementations that use a REQUIRE
mechanism, but you're choosing to sit in the fracture, pushing it
further & further apart with SRFI 55, rather than getting out of it and
helping mend it by using SRFI 7.

> > 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.

SRFI 7 _can_support_ those REQUIRE mechanisms.  The converse is _not_
_true_.  So those Schemes that use REQUIRE mechanisms _can_use_ SRFI 7,
quite trivially.  That's _not_ a fracture.

> By standardizing the latter, we can make it at least a little bit
> easier to write portably code for the majority of Scheme implementations.

This, on the other hand, _is_ a fracture, _just_ to save a couple key-
strokes!  Those implementations that separate module data from Scheme
code _cannot_ use SRFI 55, while they _can_ use SRFI 7; whereas those
that use a REQUIRE-like mechanism can use _both_.  By standardizing the
option that only _some_ can support, you're _fracturing_, Felix.  You
cannot flip the argument back around at me.

> >                                       In this situation, _YOU_ are
> > making the choice for all these implementations, and the choice will
> > cause a _fracture_!
>
> No, you don't understand.

Gee, do you think it would be very useful for me to say 'no, you don't
understand' in response to that?  It wasn't a very useful response from
you.  I suggest that you come up with something more articulate and
coherent.

Here I notice that you snipped off a significant paragraph I wrote, not
even bothering to respond to it.

> > (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.

No, it wouldn't.  Nor is REQUIRE portable across all implementations.
But _SRFI_7_is_!

> 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.

Felix, I recommend that you just try to _understand_ the situation that
you are _forcing_ Scheme into.  The way you have attempted to flip my
argument around and use it against me demonstrates that you hardly
understand it at all.