Joe Neeman <[email protected]> writes: > In other words, we have a "pop-push" and a "pop". In the context of > Reinhold's email, you were suggesting (although perhaps not seriously) > adding a "push". Now, I'm happy to have "push" and "pop," but I think > "pop-push" is a bad interface for a stack.
It is not intended as an interface for a stack. It is intended as an interface to flat context-specific settings that are either present or not, and when they are not, the values from higher contexts shine through. The only stack depths the user is supposed to be dealing with are 0 and 1, meaning that a revert will take you back to 0. However, there are programming tasks where intermediate larger stack depths make sense, and the mostly dormant stack mechanism can employ larger stack depths than 1 for this case. This was available from the Scheme level, and \temporary makes it available for LilyPond entry as well. Now the whole implementation is "stack", and the original user interface also was "stack". Changing this to "flat" while retaining the stack mechanisms for times of need was simplest accomplished by making \override pop-push. pop-push is not as a much an "interface to a stack", it is the implementation detail used for an "interface to flat variables" while a stack mechanism is already in place, and occasionally still needed. > The reason that we have gotten away with it for so long is because our > interface ensures that the stack is almost always empty anyway (since > the only way to "push" is with \once, and that always pops > immediately). Once we start talking about composability, the > deficiencies of pop-push become clear. Of course I can't vouch for Han-Wen's motivations, but I think the change to pop-first was likely made because he had decided that he did not want to continue being forced explaining composability to users who got bad surprises from its consequences. Its purpose is not an interface to a stack, but rather stopping it from being an interface to a stack. And witnessing the storm of outrage at my reopening this interface for times of need, it seems that this change was quite in the general interest of users. > What's not orthogonal here? _Every_ modifier works on \overrides > (granted, \undo will also work on \set but just because it does > not make > sense not to include this as well). \once allows a one-step > temporary > replacement, \temporary and \undo allow the start and stop of a > temporary replacement to be separately specified. > > What isn't orthogonal is that you can't express, say, \temporary in > terms of \override and \revert. That's because the most basic building block _is_ \temporary \override. \temporary _strips_ the normally desired complexity from \override. \override is perfectly equivalent to \revert + \temporary \override. That doesn't violate command orthogonality, but rather the expectation that the shortest command corresponds to the most basic conceptual building block. In terms of implementation, \temporary takes something _away_ from the normal operation of \override. > If we switch to using push and pop instead of pop-push and pop, then > push and pop become the orthogonal underpinnings of everything and > \once, \temporary, and \undo become syntactic sugar. The sugar is then > easy to explain to users because it can be expressed in terms of > commands that they already know. But if they currently stick with the commands that they already know, the only stack depths they need to be concerned with are 0 and 1: nothing else can occur. Turning override into push rather than pop+push means that everybody _must_ know the details governing stack depths of n. There may be complex commands written in terms of property changes that leave the original state, but for all the user knows, they might just store the old values elsewhere. He is not required to know that they actually use the _same_ storage mechanisms in a trickier way. And given the lack of enthusiasm for exposing the user to "programming concepts" here, making the user unable to create "stacks" of depth>1 with basic commands does not seem like the worst idea. > more > > intuitive-to-non-programmer names) makes a nicer stack interface > than > > push, pop-push and pop. > > > What is "clear" supposed to be? > > It empties the stack. That's a totally uncomposable operation cutting through all nested layers without any means of cushioning. It is a knee-in-the-groin kind exposition of the stack concept to the user: if he was only vaguely aware of it before, he will be very acutely be aware of it afterwards. > I think there is a problem, because the behaviour is not intuitive. > You're technically correct in that it is not a problem of \undo; I > believe it is a problem in \override, which should use push but > instead uses pop-push. push was the original design. Ask Han-Wen why he changed it in 2005. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
