Re: [PATCH] primitive resolution for public refs

[BT Templeton]

Noah Lavine <address@hidden> writes:

> 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.

You're probably thinking of `module-define!'; `module-set!' mutates the
variable object directly (whether it's imported from another module or
not), so it works as written, modifying both (@ (guile-user) car) and (@
(guile) car).

>> 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.

If the (guile) module and its variables were immutable by default, the
optimization would be correct. Perhaps Guile could provide something
similar to Common Lisp package locks:
<http://www.sbcl.org/manual/Package-Locks.html>

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!