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.
On Tue, 22 Jun 2004, felix wrote:
> campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx 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!)