xxxxxx@autodrip.bloodandcoffee.net wrote:
> On Sat, 19 Jun 2004, felix wrote:
>
> Sorry, but this is just an empty arguemnt about your personal taste,
> and it has absolutely no place in this argument.

Any argument is in the end about taste. Ease of use can be considered
a pure taste issue. If you want to push me into this corner, then, yes,
SRFI-55 reflects my personal taste, just as SRFI-7 does yours.

>
> Yes, SRFI 55 can't be implemented without restructuring a great deal of
> Scheme48's compiler.  I consider only one implementation's module
> system because it is the only one that I know of that has the property
> that module data can't be embedded into source data.  A quick check
> shows that RScheme's module system _seems_ to have this property as
> well, though I'm not _entirely_ sure.  But it's irrelevant that I can
> think of no others;

That's unfortunate. I think this makes both of them harder to use
than necessary. Yet, why should other implementations artifically
restrict themselves, even if they allow for more convenience?

>
> Again, this is moving to the issue of taste, which should _not_ be in
> this discussion as long as technical merit is at issue.
>

I see ease of use as a form of technical merit.

> It's amazing to see how the fact that Scheme48's & RScheme's module
> systems can't implement REQUIRE is stubbornly ignored!  I am _not_
> saying that REQUIRE-like mechanisms are inherently incompatible with
> _all_ module systems, but that they _can_ be incompatible with _some_
> module systems, whereas a separate configuration language can _always_
> be compatible with module systems.
>

Yes, as I pointed out: the shortcomings of one and a half implementations
are unfortunate, but shouldn't stand in the way over making things
easier for the average Scheme programmer.

> other hand, SRFI 0 is a mechanism for feature-based conditionals, but
> that sort of thing -- feature-based conditionals -- does _not_
> inherently impose module data into Scheme source code, so SRFI 0, which
> _does_, is flawed.  SRFI 7 duplicated some functionality if SRFI 0
> because SRFI 0 was flawed, and SRFI 7 _fixed_ the flaw: module data is
> no longer embedded into Scheme source code, but you can always expand
> the module data _into_ it, for systems where the module data _must_ be
> embedded into the source code.  SRFI 55 is modifying SRFI 0 slightly,
> eliminating the 'conditional' part, and it has the _same_flaw_ that
> SRFI 0 had.  Therefore, SRFIs 0 & 55 _unnecessarily_ alienate module
> systems that disallow embedding module data into Scheme source code,
> and this is _inherent_ in their design.  If you just can't have a real-
> time scheduler -- _regardless_ of designs inherent in SRFI 21 --, then
> of course you can't implement it; you can't implement _any_ real-time
> multithreading mechanism: there's no alienation here except by people
> who _need_ real-time multithreading.  With SRFIs 0 & 55, there's
> alienation by people who _just_personally_prefer_ embedding module data
> into Scheme source data; there is no _necessity_ involved.
>

To reiterate:

a) SRFI-55 provides functionality that SRFI-7 doesn't specify (i.e.
    loading/making accessible SRFI functionality), regardless how
    you twist the SRFI-7 specification, or the possible ways how it
    could be interpreted.
b) That SRFI-0 is inherently flawed according to your taste, doesn't
    bother me at all, I think it adequate and useful. It's also implemented
    across a broad range of implementations, so I see that as an
    indication that implementors seem to be comfortable with it and that
    they are willing to implement it.
c) That some (one, effectively) implementations are not able to support
    something along SRFI-55 is unfortunate, but should not restrict
    the abilities of other implementations. Yes, I consider those
    implementations "broken" in that regard, you are of course free
    to disagree.
d) Ease of use is an important issue to me, even if it offends some
    people's idea of what's the "Right Thing" or not.
e) `require-extension' is not restricted to be used at the interactive
    level, even though it would be useful in such a context. Additionally
    it can be handled properly inside module systems (not all, as you
    correctly point out, but most of them).

So instead of going over this endlessly, I suggest we agree to disagree.

cheers,
felix