problems with rationale & design campbell@xxxxxx (16 Jun 2004 19:49 UTC)
|
Re: problems with rationale & design
campbell@xxxxxx
(16 Jun 2004 20:54 UTC)
|
problems with rationale & design campbell@xxxxxx 16 Jun 2004 20:00 UTC
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. 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. 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_? (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...) 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! 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! 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? (Note: when I say 'program loader' in this email, I'm using a very general term; it could be a procedure (LOAD-PROGRAM <filename>), a command in an interactive command processor/REPL, a dynamic linker/ loader, a static linker, or anything. I probably ought to have come up with better terminology, but as long as I have this note here, it'll probably be clear enough.)