lexical distance
Peter Keller
In the R6RS spec, it says in "1.4 Definitions":
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-4.html#node_sec_1.4
--------------
Bindings follow the lexical structure of the program: When several
bindings with the same name exist, a variable refers to the binding that
is closest to it, starting with its occurrence in the program and going
from inside to outside, and referring to a top-level binding if no local
binding can be found along the way:
(define x 23)
(define y 42)
(let ((y 43))
(+ x y)) => 66
(let ((y 43))
(let ((y 44))
(+ x y))) => 67
--------------
So, my question is, what is the real meaning of "lexical structure of the
program"?
I ask because if I were to build a compiler IDE in which functions,
macros, and everything else were in seperate text spaces which could be
recombined at will, then the notion of lexical distance becomes somewhat
meaningless. An example in an IDE would be to "edit function" or "edit
macro" and you'd get a single function of macro in a text buffer for
editing purposes. Java IDEs are often like this where you only see one
object at a time in a single text buffer. APL editors are also similar.
The assumption in R6RS scheme is that multiple functions/macros/defines
must be stored in files, processed from the beginning file position to
the end file position.
Even the text above is ambiguous for what it assumes, for example, following
a strict interpretation of the above, this code should produce 42 simply
because the second binding of foo is closer to the use of it.
;;;;;;;;;;;;;;; BEGIN CODE
(define foo 10)
(display foo)(newline)
(define foo 42)
;;;;;;;;;;;;;;; END CODE
For scheme implementations which treat code forms as individual
objects not spatially related to each other, how is this ambiguity and
interpretation resolved? More abstractly, is toplevel sometimes treated
as a partitioned set in addition to a whole? Toplevel doesn't seem to
be what it claims to be...
Thank you.
-pete
William D Clinger
> Even the text above is ambiguous for what it assumes, for example, following
> a strict interpretation of the above, this code should produce 42 simply
> because the second binding of foo is closer to the use of it.
>
> ;;;;;;;;;;;;;;; BEGIN CODE
> (define foo 10)
>
> (display foo)(newline)
> (define foo 42)
> ;;;;;;;;;;;;;;; END CODE
That is not legal R6RS code.
> For scheme implementations which treat code forms as individual
> objects not spatially related to each other, how is this ambiguity and
> interpretation resolved?
Your message appears to discuss R6RS code throughout.
In R6 Scheme, implementations are required to consider
a code form's context within a library or top-level
program, plus the context provided by any identifiers
imported from other libraries. The local context is
a linear sequence of text or tokens. Multiple imports
and/or definitions of the same identifier are disallowed,
so no ambiguity can arise from those sources.
The situation in Java is similar. A Java IDE may present
a single method's code for editing, but that method's
code must still reside within the definition of some
particular class.
There are plenty of ambiguities in R6 Scheme, but I
don't see any ambiguities that arise from the points
you raise.
Will
Peter Keller
> Multiple imports and/or definitions of the same identifier are
> disallowed, so no ambiguity can arise from those sources.
I see, so in section 7.1 this statement:
"Otherwise, no identifier can be imported multiple times, defined multiple
times, or both defined and imported."
And also:
"The <library body> is the library body, consisting of a sequence of
definitions followed by a sequence of expressions."
holds for both the library body AND the toplevel of the program.
> The situation in Java is similar. A Java IDE may present
> a single method's code for editing, but that method's
> code must still reside within the definition of some
> particular class.
I see your analogy and how it applies given my new understanding that
toplevel is treated just like a library body.
> There are plenty of ambiguities in R6 Scheme, but I
> don't see any ambiguities that arise from the points
> you raise.
Thank you for your explanation. I understand how I got it wrong. I
appreciate it!
-pete