xxxxxx@autodrip.bloodandcoffee.net wrote:
> There seems to be two parts to the rationale:
>
> - SRFI 7 isn't incremental or linear, so it's not designed to work
> interactively.
> - SRFI 7 doesn't specify the precise _loading_ of features' code.
>
> I have several problems with this. To the first part, I really don't
> see any need for standardizing interactive features. If you're using a
> specific implementation's interactor, well, you're going to be doing
> stuff that's really implementation-specific anyways, and to make an
> attempt to standardize all interactive Scheme features would be simply
> silly. And anyways, SRFI 7's clauses could easily be adapted to some
> form of interactive declarations.
>
SRFI-55 is not mainly about interaction. It's one possible application,
where `require-extension' would simplify loading/importing of external
libraries (SRFIs in this case), but could be used in any other context
as well.
> The second part of the rationale is more significant. First of all,
> SRFI 7 defines a language for specifying the dependencies of a Scheme
> program. SRFI 7's intent is _not_ to specify a program loader -- for
> example, a SRFI 7 processor for which it would make no sense to perform
> loading of necessary features might be a dependency analyzer --; but
> SRFI 7 _does_ suggest that a program loader exist somewhere in a Scheme
> system that purports to support SRFI 7, and a useful program loader
> _would_ indeed load the necessary features.
I don't think one should make too much effort interpreting certain features
into overly vague specifications. If the author of SRFI-7 did indeed have
something like "loading" (in any possible sense) extension libraries into
the system, then he could have specified it as such. SRFI-55 specifies
what SRFI-7 only (and incompletely) hints at.
> If someone wrote a SRFI 7
> program loader that didn't actually load the features, why would they
> write a SRFI 55 program loader that _did_?
Sorry, I don't get the point here.
> (Unless that person had the
> initials FLW and was the author of a Scheme->C compiler based on Henry
> Baker's Cheney on the MTA garbage collection & compilation system...)
Oh, I know from good sources that this particular compiler will drop
SRFI-7 in the next release...
> Furthermore, SRFI 7 even suggests that implementations that purport to
> 'support SRFI 7' provide a front end to their compilers or program
> loaders for SRFI 7, whereas SRFI 55 doesn't even suggest that!
No, why should it? `require-extension' *is* the front end.
What are you talking about?
>
> Now, I am also troubled by the design of SRFI 55. It has the _exact_
> same problems that Kelsey argued against in the SRFI 0 discussion list
> and for which reason Kelsey 'responded' to SRFI 0 with SRFI 7!
> Specifically, it is embedded in Scheme, which is utterly incompatible
> with certain module system designs that cleanly separate the metadata
> that the module system provides about the source and the source data
> itself; in an example such module system, Scheme48's, it would require
> absolute contortion to the system to make this operate correctly, and
> so I can envision the Scheme48 developers to, indeed, _not_ provide a
> useful program loader for SRFI 55, while it already has a useful one
> for SRFI 7!
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.
>
> Now, if all you want is for SRFI 7 to specify that, if a program
> loader is supported, it should try to load the necessary features, if
> possible, (way too many conditional clauses there...sorry...), why
> isn't this SRFI just a brief amendment to the wording of SRFI 7?
Because I find SRFI-7 incredible inconvenient and total overkill
(IMHO, AFAICT, etc. etc.).
Why do I have to learn a new language just to use `iota'? Please survey
the current Scheme implementations, you will be surprised how many
of them provide `require-extension' in one form or the other.
cheers,
felix
