Re: `undefine'

[Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE>]

> This can't be fixed without the unmemoization protocol.  If you want
> to understand why, it may be interesting to study how the evaluator
> replaces references to bindings with ilocs and glocs.

(define (b) (display a))
is re-written to -> proc b  code (@display @a)
where @display and @a are memoized vcells which have been looked up
by scm_environment_cell().

There are exactly two cases where this memoization will lead to false results:
a) when a module is re-loaded or a symbol is undefined
b) when a new definition shadows a definition imported for another module


> Each space must keep a list of GLOCs it has created for the
> interpreter.  Each space must also register itself as a ``observer'' of
> each space whose bindings it cares about.  Then, when a space does
> something which changes its visible bindings, it invokes its own
> @code{update} function.  Each space's @code{update} function reverts
> all the GLOCs in its GLOC list to ordinary variable references, and then
> recurses on its observers.  The interpreter will re-memoize the variable
> references when it next visits them.


Yeah! Thank you very much.  It seems also that Scheme48 uses s similar
technique.  Scheme48 doesn't support undefine but it supports shadowing:

 werner> (define a (+ a 1))
 werner> a
13
 werner> ,in waldi
 waldi> (define a 99)
 waldi> (b)

Note: Replaced location
      #{Location #(#{Location 5663 a hugo} (117) #{Location 5662 a werner})}
      #{Location 5662 a werner}
      117


Jost