guile-devel
[Top][All Lists]
Advanced

[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



reply via email to

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