Kenneth Tilton wrote:
>
> Ramarren wrote:
>> On Tue, Mar 24, 2009 at 9:00 PM, Kenneth Tilton <kentil...@gmail.com> wrote:
>>> btw, If this version of Cells-Gtk is built on the latest Cells the
>>> with-integrity call can be omitted (but is harmless) because the SETF code
>>> will notice no one is managing integrity and take over integrity management
>>> itself.
>> Well, it is built on slightly modified Cells from common-lisp.net CVS,
>> so I don't know how latest it is. It says last modified five months
>> ago. I tried looking into the source, but the SETF in question
>> contains a COND which completely confused me... I mean, if it signals
>> an error saying that it has to be wrapped in with-integrity, then why
>> doesn't it just do it, especially considering that it does just that
>> in the other branch?
>
> Well, first of all, the second branch happens only if we are not already
> under integrity management and is just being helpful as I indicated by
> auto-supplying IM. That is just a little convenience.
>
> Once we are under IM, one SETF needs to finish before the next begins.
> (Yes, wild and crazy types can bind *defer-changes* to nil and wreak
> havoc. Let's forget them.)
>
> Now consider what happens if the internals silently defers a setf when
> it sees IM underway already IIRC:
>
> (print (setf (^x) 42))
> -> a closure in which the desired state change gets bottled up until it
> is time to run. No, wait. I think I changed that to actually say
> :DEFERRED or something. And more confusing (they likely will not think
> to capture and log the the return value of the SETF since we all know
> what that has to be, right? 42!) no propagation happens.
No, sorry, propagation happens, just not when we expect it. But in the
rare case where one might:
(setf (^x) 42)
(if (= (^x) 42)...
The test will fail because X still holds the old value.
kt
_______________________________________________
cells-gtk-devel site list
cells-gtk-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/cells-gtk-devel
