This page is part of the web mail archives of SRFI 72 from before July 7th, 2015. The new archives for SRFI 72 contain all messages, not just those from before July 7th, 2015.
On Wed, 31 Aug 2005, Keith Wright wrote:
Although the above quotation occurs three times almost verbatim, in the abstract, the introduction, and the specification, it does not get any clearer with repetition. As Brian Smith used the term "reflective tower" it referred to an interpreter for a language that could express modifications to its own interpreter. I don't think that's what you are after, is it?
The second mention of the "infinite reflective tower" is followed by a reference [11] to Richard Kelsey and Jonathan Rees - The Scheme 48 implementation http://s48.org/ but a couple hours searching the Scheme 48 manual at that web site turned up no mention of reflective towers, and not much about macro expansion.
I'll try to rewrite this more clearly. I mean a reflective tower in the Scheme 48 sense, also called a syntactic tower by the authors, who indeed criticise the word "reflective" as a misnomer, though it seems to be widespread in the Scheme folklore. The Scheme 48 manual is notoriously cryptic, to the point of unusability, but there is a mention on the page:
http://s48.org/1.2/manual/s48manual_33.htmlIf someone else has a better reference to the Scheme 48 tower, I'd be grateful for it.
Perhaps a better reference would be <a href="http://www2.parc.com/csl/groups/sda/projects/reflection96/abstracts/queinnec.html";> Queinnec - Macroexpansion Reflective Tower</a>
I'll add the reference.
A couple of examples of odd scope rules just isn't enough for me to figure out the plan. This seems to be a very big change from the previous proposal, and not like anything that I understand well.* Added BEGIN-FOR-SYNTAX.
Maybe this will help: In the example
(define x 1)
(begin-for-syntax (define x 2))
(let-syntax ((m (lambda (form)
(quasisyntax (list x ,x)))))
(m)) ==> (1 2)
one would get different answers depending on whether you evaluate the
sequence of expressions one by one in the REPL, or compile the whole thing and
then run it, *unless* the runtime x and the expand-time x live in separate
namespaces or, equivalently, runtime and expand-time variables have separate
lexical scopes.
It is still lexical scoping. Any programmer worth her salt will know that the first x in (list x ,x) denotes a runtime variable and the second x an expand-time variable, and be able to look up the appropriate lexically preceding binding for each.
I consider this "invariance under compilation" property the right thing to do.
The phrase:... the hygiene algorithm of this SRFI implements a refinement of lexical scoping that takes into account the level of use of an identifier in determining its meaning.might be better worded as: the algorithm of this SRFI totally ignores lexical scoping by making the meaning of an identifier depend upon an invisible property called its "level" rather than its position in the source code. ...but I have already stated my objections when you first brought up this idea.
I think it is clear that one has different environment bindings at expansion time and at runtime. In fact, there is no reason that the expansion-time bindings have to implement standard Scheme. For example, the compile-time CAR can be different from the runtim CAR. So the compile-time language can be different from the runtim language.
For argument's sake, let's call the runtime-language Scheme and the compile-time language Pascal. Now Pascal binding forms and Scheme binding forms a priori have nothing to do with each other, so I would be very surprised if the inner Pascal LET were to affect the x in (syntax x) at all in the following.
(let ((x 1))
(let-syntax ((m (lambda (form)
(let ((x 2))
(syntax x)))))
(m))) ==> 1
Indeed, the x in (syntax x) represents a Scheme variable, not a Pascal variable.
It should therefore be bound by the enclosing outer Scheme LET. In other
words, Scheme code and Pascal code should have separate lexical scopes.
* Added SYNTACTIC-WIND.Oy.
This allows one to do a computation before and after expanding a block of code. It is useful for maintaining environments at expansion time when implementing things like syntax-case and pattern matchers. For example, in the syntax-case macros I used it for maintaining the environment of pattern variables.
I included it because without it I do not know how to write syntax-case as a library macro. I do not wish to specify syntax-case as a primitive.
* Removed EXPAND.Why?
Because just like EVAL, EXPAND really does not make sense without a second argument specifying the environment. I did not wish to overcomplicate the SRFI with a complicated explanation (and implementation) of a primitive that is used mainly for debugging.
...and if it is gone, why is this code in the section
on the reflective tower?
(for-each (lambda (form) (eval (expand form))) sequence)
== (for-each eval (map-in-order expand sequence))
The "schematically" was meant to indicate that it is just a pseudocode expression of the previous verbal phrase.
In other words, would the old srfi be compatible with the reflective tower, except that it would give errors (identifer used outside its scope of definition) in some cases where the tower would find and use a binding occurrence that would appear to be shadowed?
My view is that it is just wrong for a binding form in one phase to affect variables in another phase at all. I consider the out-of-scope errors in comparable macro systems a bug.
Cheers Andre