On Thu, 17 Jun 2004, felix wrote: > xxxxxx@autodrip.bloodandcoffee.net 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_ language! Or: Why do I have to learn the new REQUIRE-EXTENSION special form just to use IOTA?
