On Tue, 22 Jun 2004, felix wrote:

> xxxxxx@autodrip.bloodandcoffee.net wrote:
>
> >>I have answered that already. Apparently not to your full satisfaction.
> >>I have nothing to add.
> >
> > You have given _no_answer_ but 'my tastes disagree,' and your tastes
> > are _nowhere_near_ as important as valid technical merit, which you
> > have given _no_ indication of in this SRFI.  Saying 'it's too
> > complicated' is, first of all, entirely subjective -- there go your
> > tastes again --, and moreover demonstrably over-dramatized.
>
> I did say what I consider technical merit, but you chose to ignore it.

Is the only technical merit you ever considser your personal taste?
That's all that you seem to be considering here, anyway.

> >>>This problem is _easily_solved_ with a suggestion I have made _many_
> >>>times -- though which you seem to have readily ignored --: just make an
> >>>amendment to SRFI 7 that specifies this!
> >>
> >>No, I won't do that. Otherwise SRFI-55 wouldn't have been submitted.
> >
> > Huh?  SRFI 55 wouldn't have been submitted if it were merely an
> > amendment to SRFI 7?
>
> I (we, actually) wouldn't have submitted SRFI-55, if we would have
> been interested in amending SRFI-7 (because then we would have done
> so). It's quite easy to understand, IMHO.

Sorry, I think we're getting tangled up in terminology.  Perhaps what
you're referring to by 'SRFI 55' is the current specification, whereas
what I mean is just this SRFI in general, be it an amendment to SRFI 7,
REQUIRE, or whatever -- something related to features.

> >>I don't like SRFI-7, for reasons that I already described.
> >
> > This alone is _no_reason_ to deliberately alienate certain module
> > systems.
>
> I think "alienate" is too strong, and indicates that you
> just get a little bit too emotional over the whole issue.
>
> As I said before, If Scheme48's module system is not able to
> cope with require-extension, then it's unfortunate, but can't
> be helped.

Yes, it _can_: by using a separate configuration language, rather than
embedding module data into Scheme code!

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

> > As I said earlier, a significant reason for why SRFI 7 isn't widely
> > used because it's not very widely implemented, and a significant reason
> > that it's not widely implemented because it's not widely used.  That's
> > no basis for technical argument.
>
> It is of course a basis for a technical argument. Sometimes one
> should look at the existing situation and draw conclusions from
> actual, practical use - from experience, so to speak. Implementors
> like to add SRFIs to their feature-list, and SRFI-7 isn't particularly
> hard to implement, so why are so few implementations supporting
> it? Did it stop implementors to add support for certain SRFIs, when
> they where freshly finalized, even though nobody was actually using them,
> yet? Of course not (they were new after all).

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.

> > You just said that certain implementations shouldn't restrict others.
> > SRFI 55 -- effectively, Chicken, for the sake of this point --
>
> Interesting... Chicken? Why not PLT? Are you trying to say something
> here?

I chose it just because it's an implementation that supports something
like REQUIRE.  Chicken was the first implementation that came to mind
while writing that sentence.

> >                                                                is
> > restricting Schemes to module systems that embed module data in Scheme
> > code, whereas SRFI 7 is not.  Therefore you just contradicted yourself
> > by saying that certain implementations shouldn't restrict others while
> > at the same time supporting one that does.
>
> 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.  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.

With your arguments of 'it's cleaner & simpler,' those implementations
that _can_ support a REQUIRE mechanism will probably be led to believe
it's a better thing to do.  But those implementations that _can't_ will
be left trying to convince the others that they're being left out and
alienated _completely_unnecessarily_.  The separate configuration
language is _NOT_ much more complicated, and it does _NOT_ arbitrarily
alienate certain implementations.

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_.  In this situation, _YOU_ are
making the choice for all these implementations, and the choice will
cause a _fracture_!

If there were SRFIs only for a separate configuration language, the
implementations that depend on one could easily manage with the
SRFIlized one, and those that do not can _also_ easily manage.  There's
_no_ fracture there, there are _hardly_ any more added keystrokes, and
everyone is happy except for the few who mourn that little bit of white
space on their screen that was filled in with SRFI 7 code.  This choice
_doesn't_ have to influence the native module system in a Scheme, and
it _doesn't_ cause fracture & alienation of certain implementations.

(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!)