On May 27, 2011, at 10:45 AM, John Cowan wrote: [ ... many interesting comments ... ] John's comments lead me to identify an issue which may result in modest confusion and in thinking at cross-purposes: Please correct me if I am wrong, but it appears that there are at least two models of what a Scheme implementation is. The first is a separate compilation model, with code created in a text editor or in a custom integrated development environment, and then presented to a compiler that may or may not have access to certain things (models, features, et cetera) at compile-time, that generates a stand-alone program (which may possibly need some kind of limited run-time support system, as do various other languages). The second is a stand-alone interpreter, that comes up running a read/eval/print loop. Compilation of a sort is possible in such an environment, in the form of transformations, bindings, and other optimizations of interpreted code, but there is no separate compile-time environment. The implementations I have created are all of this kind; the closest Wraith Scheme gets to stand-alone programs is a facility to mouse a saved world and have the interpreter open, load the world, and start running a specified program. In the latter kind of implementation, many of the compile-time/ run-time distinctions that John mentions do not exist, in the sense that *everything* happens within a run-time environment. Of course, some things, such as fetching modules and extracting imports from them, and such as compilation in the limited sense I just mentioned, need only happen once for a particular program, which may then be run many times in the same instantiation of the interpreter, or may perhaps be preserved in a saved world for subsequent use. Thus if I understand things correctly, for example, in a stand-alone interpreter there is no real benefit to using "cond-expand" as opposed to straight "cond" with "memv" and a list of features. I do see that "cond-expand" makes good sense with separate compilation. Furthermore -- though I will have to think a good deal more to be certain -- it looks as if the obvious way to have a stand-alone Scheme interpreter handle modules is to expect the user to load the files that contain module definitions, and implement "module" as syntax that creates some kind of a functional object that responds appropriately to "import" with the various <import set>s. That looks like a real mess to do, but I will take your (collective) word that the R6 module syntax is worth it for the sake of separately compiled Scheme implementations. I have rather the feeling that a good deal of the WG1 R7 report was written with separate compilation in mind; I am wondering whether additional text is appropriate to indicate how stand-alone interpreters are supposed to handle some of the features that have been added since R5. Unfortunately, I do not know enough about the new features to have a clear sense of what advice might be missing, so I am not sure what questions to ask or what comments to make. Out of curiosity, does anyone have any idea as to what proportion of currently-available Scheme implementations are stand-alone interpreters? Jay Reynolds Freeman ------------------------------- Jay_Reynolds_Freeman@mac.com http://web.mac.com/Jay_Reynolds_Freeman _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
