On Sat, Oct 13, 2012 at 2:29 PM, David Kastrup
<address@hidden> wrote:
Joe Neeman <
address@hidden> writes:
> On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup <
address@hidden> wrote:
>
>
>
>
> No. I am just pissed at the people clamoring for more ignorance,
> more
>
> bugs, and less control.
>
> If you are referring to Werner's and Reinhold's comments, I think you
> may not be reading them as the authors intended. In particular, I
> believe that Reinhold was merely objecting to the names "push" and
> "pop" as being opaque to non-programmers,
To me it is not only this inconsitency, but rather that the names
push/pop come from programming languages and concepts.
Lately, I have seen many suggestions that would turn lilypond more
^^^^^
into a programming language and away from being a description of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
music. Now, while lilypond really is a programming language, in the
past we have tried to hide the concepts (e.g. queue theory) from the
user, with more or less success.
David's attempts to get rid of the #' in propery names is a great step
in this direction, but using push/pop would be a huge step in the
wrong direction, IMO.
> while Werner was complaining that the plethora of new
> context-manipulation functions have become confusing.
That makes it sound like it would be a chaotic bunch. And what do we
have?
\override overwrites the last definition
\revert throws it away/reestablishes the previous if not overwritten.
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. 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.
So my proposed set of orthogonal commands would be push and pop (again, with more intuitive names). I also suggest adding clear for convenience. Everything else would be syntactic sugar on push and pop.
Then we have modifiers for possibly multiple combined overrides, as
those are for example available in large numbers in property-init.ly and
we want to be able to use them for as many things as possible without
having to retype them with modifications.
\once \override non-destructively masks the definition for one
time step, then restores
\temporary \override non-destructively masks the last definition
\undo \override drops like corresponding \reverts would
A \tweak goes through a music object rather than through context
properties, so we get
\single \override (again an \override prefix) converts into one or more
tweaks
All those are separate tools, apply in the same manner to one or
multiple overrides, to get a clear effect derived from the original
\override-based command, and complementing each other in functionality.
People shout "I want fewer", but they are a set. It's like saying you
want a smaller set of spanners, so you leave out every second one. But
that means that you won't be able to do a random subset of required
tasks because the spanners are a full set. You can't just randomly
leave out some and expect to be able to still do every job.
> I interpret his comments as a request for orthogonalization rather
> than a complaint about the options that the new commands
> introduce.
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. 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.
\single converts into a different grob modifier mechanism.
No, the complaint was clear, from several parties:
I get the feeling that we have to completely reconsider how \set,
\revert, and friends are named and used. Your clean-ups and
reorganization of the syntax reveal more and more inconsistencies,
and my head starts aching if I think of \once, \undo, and so on.
[...]
In other words, we have \override, \tweak, \set, \revert, \unset,
\undo, \single (and maybe more). It's getting confusing, at least
for me. I'd prefer to decrease the number of such functions, not
increase them (without deleting functionality, of course).
[...]
Plus \once and now \temporary. I agree this menagerie is going to
be far more confusing to users than the occasional unexpected result
after calling \crossStaff or \harmonicByFret - which no one has ever
noticed. Users get quite confused enough with just \override,
\revert, \set, \unset and \tweak.
We're going too far in this direction now.
> Now, it's true that the comments may not have been entirely
> constructive as they didn't propose alternatives, but I also don't
> think anyone claimed that your proposal is worse than the status quo.
The last comment above states "we're going too far in this direction
now", calls the commands a "confusing menagerie" and states that nobody
noticed the kind of bugs one can fix with that anyway. "quite confused
enough" clearly strongly speaks against providing any more commands,
preferring to stay with problems instead.
> For what it's worth, I think push, pop and clear (perhaps with 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.
> I also think that "undo" should be rethought in light of this recent
> discussion. In particular, this discussion has made me realize that
> "undo" doesn't just reverse the effect of an override, since after
> \override Something #'color = #green \override Something #'color =
> #red \undo\override Something #'color = #red, then the color is not
> back to green as one might think.
An \override overwrites the last value if any, and it is gone. That's
not a problem of \undo.
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.
> What if we gave the users a "push, pop and clear" interface and we
> made overrides use "push" and \oneVoice use "clear"? This solves the
> \voiceOne\voiceTwo\oneVoice
> problem
No. Quite a few commands intended to be used "at bottom" have a
combination of overrides and reverts. Having the reverts remove
everything to bottom of stack and the overrides not is not going to make
things more predictable.
I am proposing that \revert do a pop, not a clear. I would then change the definition of \oneVoice to do a clear rather than a pop.
> \override Something #'color = #green
> \override Something #'color = #red
> \undo\override Something #'color = #green
> go back to the pre-green color.
Not useful. This is primarily of interest when the outer and the middle
part are provided from different sources and don't know what the
respective other is, and if the middle part happened to be \override
Something #'color = #green for whatever reason, suddenly the scope of
the \undo would flip.
Ok, that's a good point. It still seems a little strange to me, though, that
\undo\override Something #'color = #red
will actually reverse the effect of
\override Something #'color = #green
Cheers,
Joe