Re: problems with rationale & design felix 17 Jun 2004 05:25 UTC
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