[Scheme-reports] General comments on the draft WG1 R7 report. Jay Reynolds Freeman (27 May 2011 02:12 UTC)
Re: [Scheme-reports] General comments on the draft WG1 R7 report. Jay Reynolds Freeman (28 May 2011 06:44 UTC)
Re: [Scheme-reports] General comments on the draft WG1 R7 report. Shiro Kawai (28 May 2011 08:09 UTC)
Re: [Scheme-reports] General comments on the draft WG1 R7 report. Jay Reynolds Freeman (28 May 2011 18:25 UTC)
Re: [Scheme-reports] General comments on the draft WG1 R7 report. Jay Reynolds Freeman (29 May 2011 04:26 UTC)

Re: [Scheme-reports] General comments on the draft WG1 R7 report. Shiro Kawai 28 May 2011 08:08 UTC

There are many interesting topics in this thread, but I just jump in
to answer to the last question,
in hope of providing a datapoint.

You seem to suggest there's a two complete modes, separate compilation
and integrated
interpreter.   But actually these are two ends of continuous spectrum,
and I guess many
implementations these days fall somewhere between them.

Gauche provides an interactive REPL by default.   Under the hood,
however, it compiles
each toplevel expression, then executes it.  So, even in
non-batch-compiling mode,
cond-expand comes handy if one of the arms uses a *syntax* that are
not supported
in the running instance.   If cond-expand were replaced by run-time check with
cond, then every clause of cond would be compiled no matter how the feature set
is, resulting compile-time error if one of the clause is using
unsupported syntax.

So, even for REPL implementations, phase separation is a concern.

On Fri, May 27, 2011 at 8:41 PM, Jay Reynolds Freeman
<jay_reynolds_freeman@mac.com> wrote:
> 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
>

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports