[PRL] scope of top-level defines

[Matthias Felleisen]

On Apr 4, 2005, at 1:14 AM, Dave Herman wrote:

> I notice that in PLT Scheme, a forward reference in a LETREC that is 
> not under a LAMBDA results in an #<undefined> value, whereas a forward 
> reference in a DEFINE at the top-level of a module that is not under a 
> LAMBDA results in an error:
>
>     (letrec ([x y] [y x]) x) => #<undefined>
>
>     (define x y)
>     (define y x)
>     => error: reference to an identifier before its definition: y
>
> How do you describe the scoping semantics for the latter behavior?

The scope for x and y is the same: the entire program, including those 
parts you are going to type.

The evaluation rules are different, however. Every time you evaluate 
(define x value) you get a definition that you can use for the rest of 
the time. (You can change the definition or a denotational semanticist 
will say change the content of the location with set!. Irrelevant.) 
When you encounter

  (define z expression)

You need to evaluate expression in the current set of definitions. If 
this evaluation refers to an identifier for which you don't have a 
value yet, you evaluation is stuck. If you're an MList, you will sit 
down and design a type system to avoid such "variable not found" errors 
:-). If you're from Cornell, you think you have to wave your hands. 
Otherwise you're happy because you have definitive rules for scoping 
and evaluation.

-- Matthias



> It isn't simply that top-level names aren't allowed to be bound to 
> #<undefined> values, because I can say:
>
>     (define undefined (letrec ([x y] [y x]) x))
>
> Do you just essentially specify that forward references must be under 
> a LAMBDA (or a macro invocation that expands to a LAMBDA etc etc)?
>
> Thanks,
> Dave
>
> _______________________________________________
> PRL mailing list
> PRL at lists.ccs.neu.edu
> https://lists.ccs.neu.edu/bin/listinfo/prl