[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 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

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

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

Jay Reynolds Freeman

Scheme-reports mailing list