Re: Trouble understanding define (!)

[Neil Jerram <neil at ossau dot uklinux dot net>]

Thanks, that's very helpful.  To summarise then,

- The new module system never copies bindings from one environment
  into another; instead the current eval-environment holds references
  to any imported environments.

- There is however a cache in the eval-environment so that repeated
  binding lookups are fast.  (In this sense, you might say that
  bindings are copied into the cache, but this is purely a performance
  optimization.)

- Variable references and "set!" both use the "nearest" available
  binding in the eval-environment and its imports (recursively).

- define only checks for a binding in the eval-environment (not in its
  imports), and creates a new binding in the eval-environment if none
  such already exists.

- undefine only removes a binding in the eval-environment (not any
  imported bindings)

Presumably defined? only checks for a binding in the eval-environment,
so that it matches define and undefine.

Now I just want to work out what these answers imply for the behaviour
of define-generic and define-method in GOOPS.

Regards,

        Neil

   From: Jost Boekemeier <jostobfe@calvados.zrz.TU-Berlin.DE>
   Date: 17 Jan 2000 20:32:00 +0100

   Neil Jerram <neil@ossau.uklinux.net> writes:

   > the current one, and in the theory, so "try it and find out" is not
   > really a sufficient answer!)

   >From the user's point of view a module behaves just like 
   the eval-environment.

   -> http://www.user.tu-berlin.de/~jostobfe/


   > That seems clear enough, but what about an existing binding that is
   > imported from another module?

   If you import a binding from another eval-environment and create
   a new binding in the current eval-environment the new binding
   shadows the old one.  See "Observing Changes to Environments".
   An environment update message will be send if a) a binding
   has been removed from one environment, b) a new binding
   shadows an imported binding or c) the export-environment's
   interface has been changed.

   > 
   > For example,
   > 
   > mymod.scm:
   > (define-public a 3)
   > 
   > guile> (use-modules (mymod))
   > 
   > Does the guile repl environment now contain a reference to mymod's
   > environment (i), or are mymod's bindings copied into the guile repl
   > environment?  

   Neither.  If you request the binding for a, the current
   eval-environment will create a reference in its cache, but it will not
   create a reference or binding in its local environment.


   > Finally, what happens when you ...
   > 
   > guile> (undefine a)

   The eval-environment will ask its local environment to remove
   the vcell.  After that it will broadcast an environment update message.

   (define-module (a))
   (define a 1)
   (environment-set-symbol-property! (the-environment) 'a 'in-module 'a)
   (export (a mutable-location) (a immutable-location (alias x)))

   (define-module (b))
   (module-open (ice-9 root) (a))

   (define a 2)

   a  -> 2
   x  -> 1

   (undefine a)

   a  -> 1
   x  -> 1

   (undefine a)

   a  -> 1
   x  -> 1

   (set! a 99)

   a  -> 99
   x  -> 99

   (set! x 100)  -> error, immutable-location

   (define x 100) 

   a  -> 99
   x  -> 100
   (environment-cell (the-environment) 'a #f)  -> (((a . 99) (in-module . a)))
   (environment-cell (the-environment) 'x #f)  -> (((x . 100)))

   (undefine x)

   x  -> 99
   (environment-cell (the-environment) 'x #f)  -> (((a . 99) (in-module . a)) . immutable-location)



   Regards,
   Jost