Re: \once \revert

[Carl Sorensen]

On 8/21/11 1:45 AM, "David Kastrup" <address@hidden> wrote:

> Carl Sorensen <address@hidden> writes:
> 
>> 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:
>> 
>> With this architecture, I don't think there are any surprises.
> 
> \set x = 4           ; setting the default
> \override x = 5      ; context set has 5
> \override x = 2      ; context set has 5 2, once set empty, result 5
> \once\override x = 3 ; context set has 5 2, once set has 3 5 2, result 3
> \revert x            ; context set has 2, once set has 5 2, result 5
> [wait ...]           ; context set has 2, once set cleared, result 2
> 
> So the \revert caused a change _twice_, first reverting the
> \once\override, and then reverting an additional override at the next
> time step.  If we view the once stack and the normal stack as one stack
> (which they are for the purpose of lookup), you have commands that
> manipulate entries at two different stack depths at once.

I see.  Thanks for the explanation.

> 
> I count that as a surprise, or at least a complication.

I agree.

> My suggestion
> would be
> 
> \set x = 4           ; setting the default
> \override x = 5      ; context set has 5
> \override x = 2      ; context set has 5 2, result 5
> \once\override x = 3 ; context set has 3(o) 5 2, result 3
> \revert x            ; context set has 3(o) 2, result 3
> [wait ...]           ; context set has 2 result 2
> 
Yes, this is clearly better than my proposal.

> Now of course this difference seems rather arbitrary if we have some
> linear code playing nonsense with the overrides in a wild order.  The
> difference in behavior is then more or less an intellectual game.
> 
> In reality, we'll more likely have such overrides occuring in
> independent code pieces.
> 
> If I have something like
> withlargestems = #(define-music-function ...  #{ \override ... \revert #})
> and
> justonesmallstem = #(define-music-function ... #{ \once\override ... #})
> then I want the justonesmallstem to not meddle with the the net stack from
> withlargestems even if justonesmallstem occurs at the very last command
> of a sequence with large stems.

I agree.

> 
> Anyway, this rationale for a single stack does not yet touch the
> question of how to implement the \once\revert semantics that you
> considered more logical as my "revert the topmost \once entry" proposal.
> 

I now see why you like to have \once \revert do a \revert on the \once
entry.

>>> 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.
> 
> Well, let us just say that when I am taxed with writing user-level
> documentation exhaustively describing override semantics (exhaustively
> meaning that the user does not need to revert to experimentation and
> guesswork for more complex cases), I consider myself to be in a les
> uncomfortable situation with my approach.

I agree that the semantics you propose are cleaner to explain.  It would
even be simple to add a warning if \once \revert found no \once entry on the
stack to \revert, so the user wouldn't be surprised.

> 
> Anyway, there is little point in spending all too much time discussing
> semantics when I could just be writing code.

Perhaps.  When you are working on code that will change semantics, I think
it is reasonable to have a discussion on the proposed new semantics,
separate from the code changes.  At least it's been helpful for me.

> I'll have the privilege of
> making the first draft in the manner _I_ consider right, and I intend to
> write the code clean enough that others may change it afterwards to
> implement different reasonable semantics if enough people agree.

And if the semantics are understood and agreed on beforehand, the review
will be of the code, rather than of the semantics.  Personally, I'm now
convinced of the semantics, and I trust your code writing, so I'll be much
more comfortable when you post a patch for review.

Thanks,

Carl