On 9/11/06, Frank Goenninger <frgo@mac.com> wrote:

Am 11.09.2006 um 18:12 schrieb Ken Tilton:

...

OK, two prospects: first, move the lazy attribute to the root Cell class so input Cells can be lazy.

Good. I'd buy in to this.

...

Hmmm, does this mean we should make it a slot attribute?

Yes, IMHO.

It is an interesting question because one can achieve the same end by being consistent with the Cell spec itself (and that is not too onerous, I think). Then the question is, why add an unnecessary restriction? OTOH, when would one vary the laziness of some attribute? Maybe wait for more experience. Hopefully tfb will have some good input.

Anyway, now here is the real interesting change I am looking at:

...

The domain is Cells with lazy attributes of t, :always, or :once- asked.

Currently, such lazy Cells, once they do get recalculated on being queried, propagate immediately to callers aka dependents. And have their observers invoked.

The proposed change is not to propagate to callers, but to still invoke observers. I think observers cannot be very observant if they are not notified of changes as they happen.*

Comments? Question?

I'd go along the principle that a cell should propagate the fact of being queried or changed asap.

Note however the clash with "ASAP" and lazy. :) The problem arises at the boundary of eager and lazy cells, and then the question is "what do we mean by lazy?" Just lazy to change, or also lazy to change others? I might author an eager Cell with a rule that reads a lazy Cell and be totally OK with its laziness, where I mean by "totally": I will read you when I have to based on other things changing (or me being read again). 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". kt