[Top][All Lists]

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

Re: eval

From: Neil Jerram
Subject: Re: eval
Date: 04 Feb 2001 11:03:08 +0000

>>>>> "Dirk" == Dirk Herrmann <address@hidden> writes:

    Dirk> Well, I seem to have expressed myself badly: The environment
    Dirk> will be restored by eval.  However, the question whether the
    Dirk> return value of (interaction-environment) is changed is not
    Dirk> part of 'eval any more.

A quick check: I believe that (interaction-environment) is the same as
what I've been calling (current-environment), i.e. the environment in
which the next thing that is entered will be evaluated.  Is that still
correct in your generalization?

    Dirk> Independent of whether my SOLUTION or my GENERALIZATION was
    Dirk> used, both calls to (current-module) would return the same
    Dirk> module.  The difference between the two is, that with my
    Dirk> SOLUTION the second call to (interaction-environment) would
    Dirk> return (foo), while with my GENERALIZATION the both calls to
    Dirk> (interaction-environment) would return the same module.
    Dirk> Making (interaction-environment) return (foo) could be
    Dirk> achieved by doing the following:

    Dirk>   (begin (current-module) (interaction-environment) (eval
    Dirk> '(define-module (foo)) <some environment>)
    Dirk> (set-interaction-environment the-module*) ;; this line was
    Dirk> added (current-module) (interaction-environment))

    Dirk> I. e. the control about when (interaction-environment)
    Dirk> changes is in the hand of the caller of eval.  However, the
    Dirk> name the-module* is definitely bad.

Interesting, but I can't think of any cases where it would be useful
not to do a (set-interaction-environment the-module*), i.e.  for
(interaction-environment) to be other than the selected module's
environment.  In what sense would the module then be selected?  (I
suppose we could, e.g., draw a distinction between definitions and
expressions -- evaluate definitions in the selected module but
other expressions in (interaction-environment) -- but that feels like
a dangerous way to play with the language.)

    Dirk> However, we should be aware of the fact, that all these
    Dirk> solutions are workarounds until we know how the module
    Dirk> system will work.  Our problems with eval are based on the
    Dirk> definition of 'define-module'.  If such a thing would not
    Dirk> exist in the final module system, eval could work just
    Dirk> cleanly, that is setting and restoring the current
    Dirk> environment.

Indeed.  Perhaps we could fix the current problem without dirtying
eval by putting in a special case in the REPL to recognize
(define-module ...)  expressions.  Or, slightly less hacky, use a read
hash extension:

(read-hash-extend #\m
                  (lambda (c port)
                    (let* ((module-name (read port))
                           (module (resolve-module module-name)))
                      (or (resolve-interface module-name)
                          (error "no such module" module-name))
                      (set-current-module module)
                      (display module)

I spent some time yesterday using and refining this, and found it very
useful; an example session is attached below.  It goes wrong if you
use it to step into a purified module, though: you can't get out


address@hidden guile-core]$ guile
guile> ls
ERROR: Unbound variable: ls
ABORT: (unbound-variable)
guile> #m (ice-9 ls)
#<directory (ice-9 ls) 8083c10>
guile> ls
#<procedure ls various-refs>
guile> (define old-ls ls)
guile> (define (ls . args)
...      (display "Calling ls...\n")
...      (let ((result (apply old-ls args)))
...        (display "done\n")
...        result))
guile> #m (guile-user)
#<directory (guile-user) 8082f90>
guile> (ls '(ice-9 ls))
<unnamed port>:11:1: In expression (ls (quote #)):
<unnamed port>:11:1: Unbound variable: ls
ABORT: (unbound-variable)

Type "(backtrace)" to get more information or "(debug)" to enter the debugger.
guile> (use-modules (ice-9 ls))
guile> (ls '(ls))
Calling ls...
(((ls) . #<procedure ls args>))
guile> (ls '(old-ls))
Calling ls...
(((old-ls) . #f))

reply via email to

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