[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)
(newline)
'*unspecified*)))
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
again.
Regards,
Neil
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...
done
(((ls) . #<procedure ls args>))
guile> (ls '(old-ls))
Calling ls...
done
(((old-ls) . #f))
guile>
- eval, Dirk Herrmann, 2001/02/01
- Re: eval, Dirk Herrmann, 2001/02/01
- Re: eval, Neil Jerram, 2001/02/01
- Re: eval, Dirk Herrmann, 2001/02/02
- Re: eval, Neil Jerram, 2001/02/02
- Re: eval, Dirk Herrmann, 2001/02/03
- Re: eval,
Neil Jerram <=
- Re: eval, Dirk Herrmann, 2001/02/04
- Re: eval, Neil Jerram, 2001/02/05
- Re: eval, Dirk Herrmann, 2001/02/06
- Re: eval, Dirk Herrmann, 2001/02/04
- Re: eval, Neil Jerram, 2001/02/05
- Re: eval, Dirk Herrmann, 2001/02/06
- Re: eval, Martin Grabmueller, 2001/02/06
- New module system and VM, Keisuke Nishida, 2001/02/06
- Re: eval, thi, 2001/02/17
- Re: eval, Keisuke Nishida, 2001/02/06