[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems with rationale & design

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 Thu, 17 Jun 2004, felix wrote:

> campbell@xxxxxxxxxxxxxxxxxxxxxxxxxxx wrote:
> > 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.

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

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

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?

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

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. 

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?

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.

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

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.

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

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?

> > 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.).

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 _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.

I direct you to the SRFI 0 discussion list to see further arguments
for a separate configuration language and against embedding the
feature conditional/requirement system into Scheme code, which, at the
end of the discussion, Feeley _still_ didn't counter; I don't know of
any rebuttals against the last emails Kelsey & Sperber sent arguing
for a separate configuration language.

> Why do I have to learn a new language just to use `iota'?

Oh, no!  You have to learn an _extremely_simple_dependency_declaration_


Why do I have to learn the new REQUIRE-EXTENSION special form just to
use IOTA?