Re: [PyCells] [cells-devel] Call for comment on Prospect of Lazy Cells Not Propagating Either
On 9/11/06, Ryan Forsythe ryan@pdxcb.net wrote:
On Sep 11, 2006, at 9:42 AM, Ken Tilton wrote:
btw, I should have mentioned that one obvious option is to simply make this a new attribute or variant of the lazy attribute, maybe "super-lazy".
Which is what I would vote for. "Really Always Lazy"? "Always (no I really mean it this time) Lazy"? I forsee some possible confusion between super- and always-lazy.
My guess is that if always-lazy cells (as we understand them now) sometimes should propagate and sometimes should not (ie, if we cannot come up with One Right Answer) then it should be a new attribute, in which case it should be two new attributes (lazy-calculate and lazy-propagate) replacing lazy. That certainly would give developers all the options in the world (I really do not think a third "lazy-observe" attribute would be appropriate given the meaning of "observe" <g>). But...
...I really hate introducing things without Use Cases to focus the mind. To a degree we are compromising the data integrity by letting values go out of synch with each other. Yes, they pop back into synch when read, but what about observers? If A is eager and depends on B and A has an observer that really really wants to stay on top of reality.... at this point the developer is responsible for keeping the world in order.
That is not necessarily a bad thing, unless it is unnecessary and can be handled automatically with more effort on the design side.
Jes thinkin out loud.
kt
kt wrote:
If A is eager and depends on B and A has an observer that really really
wants to stay on top of reality....
I just had Cells4 kinda thought: what if all Cells are (in some new respect) lazy unless observed (directly or indirectly thru someone that is observed)?
btw, as radical as that change sounds, I am not sure it really rises to the level of "Cells4" -- I am suggesting this only because I think it is equivalent to Cells3 (assuming one is sane enough not to have side-effects inside rules) and merely automates the identification of which cells can be lazy (or looked at another way, automates the detection of the need for eagerness.
Then the explicit thing becomes supporting a new class of much rarer (methinks) "lazy" observer whose existence would not trigger eagerness.
It would be interesting to see how much laziness ends up being deduced by this approach. The indirect eagerness (I am not observed, but I am called/used by someone who is) could get interesting.
Jes thinkin out loud.
kt
On Mon, 2006-09-11 at 15:33 -0400, Ken Tilton wrote:
kt wrote:
If A is eager and depends on B and A has an observer that really really wants to stay on top of reality....I just had Cells4 kinda thought: what if all Cells are (in some new respect) lazy unless observed (directly or indirectly thru someone that is observed)?
I was using Cells4 today :)
So, all cells are lazy. Check. Unless observed. Check. Observed = I ask for a cells value explicitly (in which case it is transiently observed,) or a GUI, etc, subscribes to it.
This makes the implementation really easy:
class Cell: def invalidate( self ): if self.state != INVALID: if self.subscibed(): invalidationSet.add( self ) self.state = INVALID for x in self.dependents: x.invalidate()
def set( self, v ): self.invalidate() self.val = v # dispatch invalidateSet stuff at some transactional boundary
btw, as radical as that change sounds, I am not sure it really rises to the level of "Cells4" -- I am suggesting this only because I think it is equivalent to Cells3 (assuming one is sane enough not to have side-effects inside rules) and merely automates the identification of which cells can be lazy (or looked at another way, automates the detection of the need for eagerness.
Yep. No side-effects, and life is simple. Eagerness is just:
class Cell: def value( self ): inputs = [ x.value() for x in self.inputs ] self.val = self.calc( *inputs ) self.state = VALID return self.val
Then the explicit thing becomes supporting a new class of much rarer (methinks) "lazy" observer whose existence would not trigger eagerness.
Ah, but once you've eliminated side-effects, lazy observers become easy to write and really useful. Consider a tabbed panel GUI on an object with same panel 1 = basic info, and panel 2 = expensive to compute stuff. The panels subscribe to the cells they care about, but when the observer callbacks are called, they do something like:
class GuiElem: def myVal( self ): return self.myCell.value()
def draw( self ): self.widget.draw( self.myVal() )
def callback( self, aCell ): if self.isVisible(): self.draw()
def onActivate( self ): self.draw()
Lovely, no? Maximal laziness - the only cost is establishing the cell dependencies.
It would be interesting to see how much laziness ends up being deduced by this approach. The indirect eagerness (I am not observed, but I am called/used by someone who is) could get interesting.
Jes thinkin out loud.
You just keep thinking, Butch. That's what you're good at.
-- mmn
On 9/12/06, Michael Naunton michael@naunton.us wrote:
On Mon, 2006-09-11 at 15:33 -0400, Ken Tilton wrote:
kt wrote:
If A is eager and depends on B and A has an observer that really really wants to stay on top of reality....I just had Cells4 kinda thought: what if all Cells are (in some new respect) lazy unless observed (directly or indirectly thru someone that is observed)?
I was using Cells4 today :)
So, all cells are lazy. Check. Unless observed. Check. Observed = I ask for a cells value explicitly (in which case it is transiently observed,) or a GUI, etc, subscribes to it.
I do not know about your C4, but no: Observation is not reading. Observation is an explicit declaration that one needs certain code to run when a cell changes value, and these explicit declarations are needed because the cells engine runs around changing values willy-nilly so there is no way for a programmer to handle those changes unless we create a mechanism dedicated to that express purpose. aka "observing". But we really need these observers to run. An observer might propagate the state "stop!!!" to an anti-lock brake system (via its own API).
We have other code that reads Cells inside Cell rules and outside them in imperative code kicked off, say, by OS events. Imperative code (again, event-handlers are an example) reads what it reads. Cells guarantees they will get accurate "current" values. But there is no need for a Cell to ensure (and in fact it would be inappropriate) such event-handling code runs because some cell-mediated state gets read during event handling. Reads from Cell rules are not interesting to rerun until somehow somewhwere we come to an Observer trying to stop a car or launch a missile or whatever.
kt
-
Ken Tilton -
Michael Naunton