xxxxxx@autodrip.bloodandcoffee.net wrote:

>
> OK.  I'd rather, then, that this not be in the 'Rationale' section.
>

Not at all. I think it's well-placed there.

> Why, then, is SRFI 55 not _just_ a specification detailing that a SRFI
> 7 program loader (whatever that is) should load the necessary code for
> features?  Why is it a completely new mechanism with the _exact_same_
> problems that the _first_ SRFI already had and that were already dealt
> with by SRFI 7?

Because we think that SRFI-7 is not simple enough and not straightforward
enough to be really useful. The fact that very few Schemes support it and
the fact that most other Schemes support something along SRFI-55 may be
an indication for a certain preference...

>
> OK.  Let me clarify a little.  Here comes along J. Random Implementor,
> making a new Scheme that he wants to be able to run lots of SRFIs.  He
> scans down the list of SRFIs, sees the points against SRFI 0, and
> decides not to implement it.  He implements the next few, and gets to
> SRFI 7.  Skipping ahead, he also sees SRFI 55.

This is mainly about making it easier for users. You put too much
emphasis on implementors.

>
> If he decides not to write a useful SRFI 7 program loader that loads the
> code for features when someone loads a SRFI 7 program that requires
> them, why would he implement SRFI 55 such that it _did_ load the
> necessary code for features?  If your answer is 'because SRFI 7 was
> too vague & didn't specify that a useful program loader should load the
> necessary code for features,' my next question is: why is this SRFI not
> just an amendment to SRFI 7 to specify that?

See above.

>
> If he decides to write a useful SRFI 7 program loader that does indeed
> load necessary code for features, he might think that SRFI 55 is just
> superfluous, or he might implement SRFI 55, and then his implementation
> would have needless clutter duplicating functionality, and, if this
> functionality is standardized, that's really not a good thing,
> especially if the duplicate has strong arguments against it, as SRFI 55
> & SRFI 0-style mechanisms, where module system data is encoded directly
> in Scheme, do.
>

Ah, now we get to the point: SRFI-55 offends your taste, just as SRFI-7
does mine. Well, fair enough.

Technically, I don't see a problem with both SRFI-0 and SRFI-55. You really
ought to study the landscape of Scheme implementations (some of them
including quite advanced module systems), specifically those that seem
to manage with one or the other form of `require'.

>
> I have a file foo.scm.  It contains a use of REQUIRE-EXTENSION, and
> does a little other stuff.  How do I load it?  The LOAD procedure in
> R5RS is vaguely underspecified and optional, just as you argue that
> SRFI 7's LOAD-PROGRAM suggestion is.

You invoke your compiler, or do other necessarily implementation-
platform-specific things. I really don't see what you are
trying to say here - well, I see it, but I don't see _why_ you are
going there.

>>
>>Fine. Then I suggest that the authors of Scheme48 do not
>>support SRFI-55. I don't have a problem with that. In fact,
>>I think that's one of the great properties of the SRFI system.
>
>
> Whoa, whoa, whoa.  Are you seriously suggesting that we _fracture_
> portability of Scheme code by having some implementations support one
> way to declare feature requirements and other implementations support
> another way, just because the first way was slightly aesthetically
> unpleasing to one or two Schemers?

Taylor, it already _is_ fractured? Didn't you notice?

On the other hand, are you seriously suggesting that we should live
with one (arguably) flawed design, without being able to propose
an alternative? Why do we have SRFI-7 then, with SRFI-0 already existing?

>
> Incredibly inconvenient?  Oh, please.  Wrap your code in
>
> (program (requires srfi-x)
> ...
> )
>
> or have a new file containing
>
> (program (requires srfi-x) (files "code.scm"))
>
> That's _hardly_ more typing than a use of REQUIRE-EXTENSION.

It's enough typing for me that I'd actually prefer

(use (srfi x))

...code...

You might find this unimportant, I don't. I write a lot of code, and a lot
of little scripts. I try to safe keystrokes wherever I can. Moreover,
I'm absolutely certain that 99% of all Scheme users would find SRFI-55
more convenient. They don't care about implementors' worries, they just
want the stuff "being there" they need.

>
> It's _not_ overkill, and indeed it is _necessary_ for some SRFIs, such
> as SRFI 10; an implementation that reads in all the source code at once
> and then processing it _cannot_ provide SRFI 10 via REQUIRE-EXTENSION
> without terrible inconveniences (such as requiring that you write it at
> an interactive prompt before loading the program -- which, um, doesn't
> exactly scale to large programs with lots of feature requirements --,
> or put the REQUIRE-EXTENSION in a separate file, at which point there
> would be no reason to use SRFI 55 instead of SRFI 7!), because SRFI 10
> may modify the reader, but the reader was already invoked and reading
> is all over by the time the Scheme compiler saw it was necessary to
> load SRFI 10.

Sure. I never actually came upon this problem with real code, but that's
a valid point that can be addressed with other, more convenient (sic)
forms (like `load', for example).

Anyway, all this doesn't convince me at all. If you don't like SRFI-55,
ignore it. If you are afraid this proposal will further fracture the
Scheme community, then I think this small "fracturing" is acceptable,
since we are not talking about a fundamental interface which will
influence a large body of code (like, say, SRFI-50...).

I just wonder why it already exists and is heavily used (albeit disguised
as `require', 'use', or various combinations of `load' and 'import').
That is what surprises me.

For example: R5RS Scheme has `load'. Effectively that's all what we need,
and `require-extension' is just a thin wrapper over it, probably doing
some module-specific stuff (like an `import', or something similar).

cheers,
felix