Hello, > I don't think I've changed the correctness wrt `module-set!' and the > like -- the current, private-refs-only optimization already exhibits the > problem you describe: > > | scheme@(guile-user)> (define old-car car) > | scheme@(guile-user)> (module-set! (current-module)
I think (current-module) should be (guile) here. Otherwise I think you will change 'car in (guile-user) and not affect (guile). But I have no doubt that this bug is real. > | 'car > | (lambda (x) (format #t "car ~A~%" x) > (old-car x))) > | scheme@(guile-user)> ,x (lambda (x) ((@@ (guile) car) x)) > | [...] > | Disassembly of #<procedure 1d23ae0 at <current input>:4:0 (x)>: > | > | 0 (assert-nargs-ee/locals 1) ;; 1 arg, 0 locals > | 2 (local-ref 0) ;; `x' > | 4 (car) > | 5 (return) > > I'm not certain it's otherwise correct; I just added a workaround for > the specific issue mentioned in the comment. Yes, you're right. That just raises the question, though: what's the right thing to do? I realized that you could argue this is part of making a closure, because it closes over the current value of variables in other modules. That doesn't match the behavior of regular closures, though: they just close over storage locations, so they can still be affected by external set!'s. Noah
