Re: A plea for local-eval in 2.0.4

[David Kastrup]

Mark H Weaver <address@hidden> writes:

> David Kastrup <address@hidden> writes:
>> I am still fuzzy on what local-eval will do when the current module at
>> the time of the-environment is different from that at the time of
>> local-eval.
>
> (the-environment) saves the module (where it is textually located) in

What does "where it is textually located" mean?

> the lexical environment object.  If (the-environment) was passed to
> `eval', that's the module specified by `eval's second parameter.
>
> If (the-environment) was passed to `primitive-eval', then that's the
> (current-module) at the time primitive-eval was called.
>
> `local-eval' passes the saved module to `eval', which temporarily
> restores it (using dynamic-wind) as the current module during both
> macro expansion and evaluation of the local expression.
> `local-compile' passes the saved module as the #:env parameter to
> `compile', which has the same effect as for `local-eval'.

>> since the current module, even if nominally the same, can contain
>> different variables at the time of local-eval, my take on that would
>> be to not make it part of the environment at all.  That is,
>> everything that is not reachable through local scopes is not part of
>> the environment.
>
> I heartily disagree.  A module is conceptually part of every lexical
> environment evaluated within that module.

What does "evaluated within a module" mean?  For me, a module provides
the fallback for everything that can't be resolved at local scope.
Basically, it is relevant for everything that "tops out" at top level.

Now the point of local-eval is that we are evaluating in a different
context than the original one.  As opposed to the variables bound in any
given lexical scope defined by its source positions, the module-level
bindings are non-constant and can change between the-environment and
local-eval.  So they are not quite at the same level.

> That this makes sense is particularly evident in the case of
> recursively defined top-level procedures.  For example, in
>
>   (define (factorial n)
>     (if (zero? n) 1 (* n (factorial (- n 1)))))
>
> it would be crazy for any lexical variable "search path" starting from
> within the definition of `factorial' to lead anywhere other than the
> module where this definition was evaluated, i.e. where the top-level
> `factorial' was bound.

(define (factorial n)
  (if (zero? n) 1 (* n (factorial (- n 1)))))

(eval `(,factorial 5) (resolve-module '(none)))

This works actually fine since apparently the "factorial" inside of the
function is bound to the actual variable of the module.  It is _not_
bound to the _value_ of the variable: if you subsequently redefine
factorial while saving a copy, calling the copy will in the recursion
call the redefinition.

However, I would have expected if I now do
(define sob factorial)
(module-remove! (current-module) factorial)
that the variable gets removed from the module but stays operative.  It
turns out that this is not the case:

guile> (define sob factorial)
guile> (module-remove! (current-module) 'factorial)
#f
guile> (factorial 3)

Backtrace:
In current input:
  25: 0* (factorial 3)

<unnamed port>:25:1: In expression (factorial 3):
<unnamed port>:25:1: Unbound variable: factorial
ABORT: (unbound-variable)
guile> (sob 3)

Backtrace:
In current input:
  26: 0* [factorial 3]
  22: 1  (if (zero? n) 1 (* n (factorial (- n 1))))
  22: 2  [* 3 ...
  22: 3*  (factorial (- n 1))

<unnamed port>:22:24: In expression (factorial (- n 1)):
<unnamed port>:22:24: Unbound variable: factorial
ABORT: (unbound-variable)
guile> (define factorial 'huh)
guile> (sob 3)

Backtrace:
In current input:
  28: 0* [factorial 3]
  22: 1  (if (zero? n) 1 (* n (factorial (- n 1))))
  22: 2  [* 3 ...
  22: 3*  [huh 2]

<unnamed port>:22:24: In expression (factorial (- n 1)):
<unnamed port>:22:24: Wrong type to apply: huh
ABORT: (misc-error)
guile> 

So I am somewhat fuzzy on what is supposed to work here how.

-- 
David Kastrup