[PEAK] Re: trellis.Set.discard

Sergey Schetinin maluke at gmail.com
Mon Nov 3 14:39:55 EST 2008


> Okay, I'm working on this now, so let's think about it.  ;-)
>
> If we _finish() all cells at the end of this "pre-transaction", then cells
> set as part of initialization will become writable again, which is good.
>  Discrete cells (whether rule or value-based) will also reset their values,
> and mark themselves as changed.
>
> By itself, that seems okay and correct.  Now let's consider what happens if
> the value was read by a cell within the pre-transaction.  I think we can
> establish that this is also safe.
>
> Consider that during a pre-transaction, a new cell's value can only read be
> read by another new cell.  This is because by definition, the
> pre-transaction must occur within a single rule execution (or non-rule
> code), and thus only uninitialized rules may be run.  (A new cell's value
> can be set, however, by either the calling rule or by a new rule.)

We also need to consider that cells can be passed to
Component.__init__. Consider this:

class C1(Component):
    val = attr()

    @maintain
    def rule(self):
        self.val = True

val = Cell()

@atomically
def test():
    c1 = C1(val=val)
    assert val.value is True

Not just the old values could be set, but also old rules run etc. In
some cases this is invalid, but in some, when the running rule didn't
run in current transaction yet it should be OK. But then, the old rule
should be undoable, the new ones shouldn't.


> From this it follows that the only rules that can be re-run by resetting a
> new discrete cell after the pre-transaction, are rules which cannot yet have
> run in the overall transaction.  Thus, the cell value reset simply leads to
> the rule being scheduled to execute later within the current transaction --
> thereby allowing it to correctly see the reset value.

This is almost true, but consider the case when we create a component
and immidiately set one of its discrete cell, this would mean that the
dependent rules will see the init value, the newly set value, but
never the reset value in between.

> Okay, I think this will work, then.  I do need to verify the current usage
> of _finish() does not do anything else that might conflict, and then make
> _finish part of the AbstractCell class (so that e.g. Constants don't have
> problems).

I have a number of small reports / suggestions, would you prefer if I
created a few new threads for them (they have nothing to do with
Set.discard anyway =) or is it ok just to list them all in one?



More information about the PEAK mailing list