[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] primitive resolution for public refs
From: |
Noah Lavine |
Subject: |
Re: [PATCH] primitive resolution for public refs |
Date: |
Mon, 12 Mar 2012 15:42:01 -0400 |
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