On Sat, Oct 13, 2012 at 2:29 PM, David Kastrup <[email protected]> wrote: > Joe Neeman <[email protected]> writes: > > > On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup <[email protected]> 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
_______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
