[R6RS] Unbound variables

[dyb at cs.indiana.edu]

> This is referring to Will's classification of exceptional situations
> that he just committed to the respository:
>
> 4.1.1   reference to unbound variable  error       should &undefined
> 5.2.1   set! (unbound variable)        error       should &undefined (!!!!!)
> 5.2.1   set! (w/o defining)            unspecified should &undefined (!!!!!)
>
> At least within a library module, I vote for turning these "should"s
> into "must"s.

I agree and would make one further change.  Within a library, there
shouldn't be any unbound variables, just unbound identifiers, and an
unbound identifier should be treated as a syntax error and cause a &syntax
exception to be raised, since there's no way of knowing what kind of
identifier it is and no reason for treating it as any particular kind.

With the traditional top level, assuming that unbound identifiers are
top-level variable references makes sense because it allows for forward
references among possibly mutually recursive procedures.  There's no
similar justification for assuming that unbound identifiers in a library
are unbound variables, since they can never become bound.

Another option would be to have two kinds of &undefined, say
&undefined-variable and &undefined-identifier.

This goes back to our discussion about when exceptions can be raised.  We
talked about permitting only &syntax exceptions to be raised prior to run
time (e.g., at expansion time).  Looking at the classification, I assume
we'll also permit &lexical exceptions to be raised prior to run time.  I
would like to permit undefined-identifier exceptions to be raised prior to
run time as well.

Kent