On May 28, 2011, at 8:26 PM, John Cowan wrote:

> It sounds like your system interleaves macro expansion with execution:
> when you see that a symbol in function position is a syntax keyword that
> is not primitive, you invoke a macro expander to determine on the spot
> what code to evaluate, and evaluate it.  You must, however, be careful
> to keep an environment around that was built when the macro was defined,
> in order to maintain hygiene.

   I believe I understand the hygiene issue and have implemented it correctly;
I will spare you paraphrasing what I have done because discussions based
on paraphrases all too often rathole based on inaccuracies thereof.

    That said, Wraith Scheme / Pixie Scheme III interleave (hygienically)
in Cowan's sense of the term(s), except that they have an enhancement whereby
the user may assert that a symbol binding is permanent.  If a binding
involving a macro is so declared, then the simple compiler I mentioned
earlier will expand the macro at compile time.  (Recall that the simple
compiler operates in the run-time environment and transforms one
S-expression that already exists in the run-time environment into another
one.)

    ("Permanence" is useful because my Schemes implement most of the
standard Scheme syntactical constructs (if, cond, let, let*, letrec ...) using
the hygienic macro system, and code would run very, very slowly if the
evaluator had to expand every such macro every time it encountered it.
With all the syntax for these forms made permanent, the compiler will
expand uses of them when it runs, and subsequent use of the compiled
code will be much faster.

    The standard Scheme procedures are similarly made permanent so that
compiled code can include direct references to the routines that implement
them rather than having to look up the binding of, e.g., "car" every time.
(A user who wishes, e.g., to change the meaning of, e.g., "car", can remove its
permanent status and install a new definition.  Uncompiled code will see the
new definition at once, but any code that was compiled while the old,
permanent one was in effect will need to be recompiled if the intent is to
use the new one.))

    My worry is thus not hygiene (though if I find bugs involving its
hygienicity I will worry a lot); my worry is that the code to ensure that
"module" works correctly when "(module whatever ...)" is evaluated in the
run-time environment, is likely to be a real mess.  It will be messy even if
my hygienic macro system works properly, and will be messy whether my
implementation is interleaving or not, since macro expansion is in either
case done in the same environment where the code containing the
expanded macro will ultimately run, and that environment must be
protected from leaking bindings.

>> I have rather the feeling that a good deal of the WG1 R7 report was
>> written with separate compilation in mind;
>
> In mind, in the sense that we didn't provide things that only
> interleaving interpreters can handle, but not *assuming* separate
> compilation, or even whole-program compilation.

    This discussion may yet be productive if we identify circumstances
in which care is required to specify the intended behavior of forms
evaluated in an interpreter, as opposed to in an implementation with
true separate compilation.

    Furthermore, if the development of Scheme proceeds along a
path in which it turns out that separate compilation has been tacitly
assumed without plenty of discussion of how such a feature ought
to work, I expect you will all yearn for the happy days of pleasant
discussion and widespread consensus that obtained when the R6
report came out.  (I am not saying "Don't do separate compilation",
I am saying "Don't let it sneak in undiscussed!")

>> Out of curiosity, does anyone have any idea as to what proportion
>> of currently-available Scheme implementations are stand-alone
>> interpreters?
>
> Of the 30 or so open-source and portable Schemes I track, only SCM is interleaving.

    At risk of being accused of word play, I will suggest that Wraith Scheme
/ Pixie Scheme III may give you a new category:  They might reasonably
be described as interleaving interleaving implementations; that is, as
implementations that interleave interleaving with non-interleaving, leaving
the standard meaning of interleaving interleaved with a different one.

    I am leaving now ... but not interleaving ...

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