[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] General comments on the draft WG1 R7 report.
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
Scheme-reports mailing list