[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: eval - environment

From: Marius Vollmer
Subject: Re: eval - environment
Date: 02 Sep 2001 18:34:11 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102

David Pirotte <address@hidden> writes:

> Neil Jerram suggested
>       (define this-module (current-module))
>       and then use `this-module' as the second eval argument rather than
>       `(interaction-environment)'
> but that is not satisfying because i don't know yet at read time
> what is the module (environment) where the method will be executed
> in

What do you mean by "the module where the method will be executed in",

It should be of no importance that `load-tuples&build-inst-1' is a
method, so let's pretend we have just a function.

    (define-module (foo)
      :use-module (mod-1)
      :use-module (mod-2))

    (define this-module (current-module))

    (define (bar)
      (eval 'EXP this-module))

In Scheme, functions `close over their lexical environment'.  That
means that the variables they can access are determined by where the
function definition is written, and not from what context the function
is called.  (I guess you know that, since it is among the first things
one learns when learning Scheme.)

In Guile, the `module of a function' is part of the lexical
environment of the function: it is the `top-level' in that
environment, so to speak.  Like the rest of the environment, the
module of a function is fixed when the function is defined.  In the
example above, the function `bar' is defined in the `foo' module,
thus, it is the foo module that is `the module of bar'.  This means
that all global variables that bar references are looked up in the foo
module (`eval' and `this-module' in the example).

Now, when executing code at the `top-level' of a file, i.e. when
executing the forms while loading a file, the function
`current-module' returns the module that will be the top-level frame
of the environments that are fixed during the execution.
Additionally, `define-module' arrange things so that `current-module'
refers to the just created module.  This is why

    (define this-module (current-module))

will set `this-module' to the foo module, which is also the module
that bar has at the top-level of its environment.

Later, when `bar' is called, `current-module' refers to whatever
module has been defined last, it does _not_ return the top-level
module from bar's environment.

So, when you want to evaluate code in the module that is also the
top-level module of bar, you can not use `current-module'.  Instead,
use the `this-module' idiom from above, or be more explicit by naming
the module:

    (define (bar)
      (eval 'EXP (resolve-module '(foo)))) 

> i could not find doc about 'local-environment and i am a little bit
> confused because i was making the assumption that unless otherwise
> specified, eval would precisly use the local-environment

You don't want to know about `local-environment'.  (It gives you
access to the data structure that implements the lexical environments,
and you should not use for ordinary things.  We are not making any
kind of guarantee about `local-environment'.)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]