Re: Naming _another_ lacking puzzle piece

[David Kastrup]

Joe Neeman <address@hidden> 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