guile-devel
[Top][All Lists]
Advanced

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

Re: eval


From: Dirk Herrmann
Subject: Re: eval
Date: Wed, 7 Feb 2001 11:29:22 +0100 (MET)

On 6 Feb 2001, Marius Vollmer wrote:

> Yep.  You might also say that `(current-module)' determines the
> environment that top-level code is executed in.  When the environment
> is closed over to form a closure (this includes `let', etc), the
> top-level environment for that closure is fixed and will not change to
> another top-level environment.
> 
> (We need to fix `begin' to actually behave this way.  This is the
> problem that Matthias is having.)

Yes, you are right.  The problem lies in the implementation of 'begin'.
Thus, all your comments about (current-module) being used for any kind of
top level evaluation are certainly true, and my idea to rename
current-module to target-module is nonsense.

BTW, my statement that there is no way to determine the evaluator's top
level environment is wrong.  You can do it as follows:

(define foo
  (let* ((tle (current-module)))
    (lambda ()
       (display "My top-level environment is: ")
       (display tle) (newline)
       (display "The current module is: ")
       (display (current-module)) (newline))))


>     (define (print-in-base n base)
>       (with-fluids ((*base* base))
>         (print-number n)))
> 
> I view the situation with `eval' and `current-module' just like this
> example.  It would simply be not good practice for `eval' to let
> changes to `current-module' leak.  If the user wants that, he can use
> `eval-in-current-module', which behaves differently.

I have changed my mind on this issue.  Yes, eval should be a
'save-module-excursion'.  However, there is only one point left that I am
not happy with:  The name eval-in-current-module.  I think we should try
to find some different name here.  eval-in-current-module sounds as if it
just means (eval expr (current-module)), but there is more to it, since it
does not do a 'save-module-excursion'.  I admit, though, that it is
difficult to think of a good name.  However, I will give some ideas that
may at least be used as a basis for inspiration for others:

eval*
  This one avoids the naming problem at all.
eval/no-module-save
eval/no-save-module
  One of these might be a good choice.
eval/define-module
eval/switch-module
eval/goto-module
  These would still take an environment parameter, thus if you want the
  expression to be evaluated in (current-module) you would have to specify
  that.  Since (current-module) will probably be the typical choice, this
  requires more typing, but the module-changing nature of the functions
  are explicit.

Best regards,
Dirk Herrmann




reply via email to

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