Re: \once \revert

[Carl Sorensen]

On 8/19/11 2:57 PM, "David Kastrup" <address@hidden> wrote:

> Carl Sorensen <address@hidden> writes:
> 
>> On 8/19/11 10:15 AM, "David Kastrup" <address@hidden> wrote:
>>> 
>>> Up to now, \once \revert is not really documented nor used.  I have not
>>> yet dug through the existing code in order to figure out what it does if
>>> anything (most likely ignoring \once, but not sure).
>> 
>> I would expect that \once \revert would revert an \override for the
>> current time step only (meaning events whose start time is the current
>> moment).  For any events whose start time is other than the current
>> moment, the \override would continue to apply.
>>> 
>>> In order to not have the override/revert stack get into unexpected
>>> interactions, I want to change \once\override to be impervious to
>>> normal reverts.
>> 
>> This seems to me to be a wise decision.  \once \override is a
>> statement that you are creating an override for everything happening
>> at the current moment; reverts would not seem to apply.
> 
> The main problem is that \once\override comes with its own implicit
> revert at the end of the time step, and when this implicit revert
> applies to a different \override, things get surprising.  If this
> implicit revert is made special so that it will only ever apply to its
> corresponding \override, then having other \reverts match the
> \once\override will seem surprising.

Let me see if I can state your concern with an example.

\override x = 1
\once \override x = 2
\override x = 3


At the current time step, you want to have x = 3, because of the
last-encountered override.

Then at the next time step, you want to have x = 3, because of the last
encountered override.

But if the \once \override x = 2 is canceled by an implicit revert, there is
the potential to have x = 1 at the next time step, which is a
counterintuitive and therefore wrong result.

I can see that this is not a desirable outcome.

My thought for the architecture is to have two sets of properties -- the
context set and the \once set.

Let me explain my thought.

Before any of these commands is issued, the context property set has x = 4.
The \once set is empty, because there has been no \once issued at this time.

when \override x = 1 is received, the context set gets an x=1 prepended (and
put on the stack, I suppose -- I'm not sure exactly how this is implemented
as a stack).

When \once \override x=2 is received, the context set gets copied to the
\once set, because we want to base the \once set on the current context set.
Then x=2 is put on the \once set, but not on the context set.

When \override x=3 is received, it's put on both the \once set and the
context set.

When it's time to get a property, since the \once set is not null, we get
the value from the \once set.

At the next time step, we set the \once set back to null, because there are
no \once overrides.  We don't need an implicit revert; we just forget the
\once set.

This comes at the price of carrying a second set of context properties when
we have a \once.  But that happens very rarely.  So really, we have the cost
of carrying an empty list around.

Under this architecture, \once means "if the \once set is empty, copy it
from the current context properties"

\override means "apply the override to the context set.  If the \once set is
not empty, also apply it to the \once set".

\revert means "apply the revert to the context set.  If the \once set is not
empty, also apply it to the \once set."

With this architecture, I don't think there are any surprises.

> 
>> I have no idea whether there is a sensible use, either, but it is
>> logically consistent, IMO.
> 
> It is also logically consistent to let the prefix \once make the
> following operation work on the set of \once overrides, as opposed to
> the set of not-\once overrides.  And the sets differ by having the \once
> overrides be autocleared at the end of the timestep.

As described above, I'd have \once work on the \once overrides, but I'd have
not-\once work on both sets.


Thanks for listening.

Carl