On May 28, 2011, at 9:48 AM, Andre van Tonder wrote: > On Fri, 27 May 2011, Jay Reynolds Freeman wrote: > >> 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. > > Even interpreters have needs to load libraries of bindings, either > system bindings (say, the usual R5RS bindings) or user libraries, > while NOT exposing auxiliary bindings to the user. It is mostly possible to do this hiding of > auxiliary bindings with LET(REC(*)) or LET(REC)-SYNTAX, but this is > usually very awkward for large libraries since this is really not what > these primitives are meant for. Precisely. What is likely going to be a mess is implementing syntax for "module", et cetera, to hide auxiliary bindings without the user having to go to the trouble to write the letrecs et cetera. > What I am trying to say is that modules are primarily for managing, > hiding, and exposing bindings, to build programs in a compositional > manner. This is just as important if your system is interpreted. > This has nothing to do with separate compilation. I agree completely; the problem is doing it! Wraith Scheme has no concept of separate compilation or of a precompiled file (such as a library) which can be loaded as such into a runtime environment. (Wraith Scheme does use world files, which are in essence snapshots of a complete run-time environment, whose loading completely overwrites the current environment and restarts the one represented by the saved world; you can't load one world into another, you can only overwrite one world with another.) The way you get executable code in Wraith Scheme is: (1) Load *source* code, thereby straightforwardly creating unoptimized S-expressions that will take a whole lot of time and effort for the "eval" part of the read/eval/print loop to deal with. (All "load" does in Wraith Scheme is deliver the file to be loaded to the top-level read/eval/print loop, and all the reader does is parse S-expressions syntactically and deliver the result to the "eval" part of the loop, *within* the top-level environment.) (2) Optionally, and with a couple of optional extra optimizations, transform the S-expressions from (1) into more optimized forms that take less time when processed by the "eval" part of the read/eval/print loop. This transformation is what Wraith Scheme's compiler does: It works S-expression to S-expression, *within* the interpreted environment. There are only two ways for Wraith Scheme to capture code that has in any sense been modularized: (A) Include source code for what is to be captured into the source files loaded in (1) above, or (B) Load into the run-time environment something that represents the module, and provide syntax for extracting bindings from it; (and by all means hide any auxiliary bindings used in whatever loaded entity represents the module). Implementing syntax so that the "eval" part of the REPL will handle "module" so as to hide internal bindings, is precisely the mess -- er, let's be optimistic, the challenge that I am anticipating. Incidentally, the way Wraith Scheme / Pixie Scheme III get their initial bindings -- system / R5 -- is by loading a world provided by me that has all of those bindings already in it. Users can create saved worlds of their own with additional bindings in them, but each such saved world is necessarily a descendant of the original world that I provide, and so has all the original bindings in it as well, unless of course the user has overwritten some of them. 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