Re: Naming _another_ lacking puzzle piece
Joe Neeman joenee...@gmail.com writes: On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup d...@gnu.org wrote: You are viewing this from the stack angle. But that is a complex view already. The actual user view is A. \override sets a context-specific property value \revert removes a context-specific property value This works reliably. If I ever need more complex stuff than that, I can look it up. And to make the this works reliably part work, we won't expose any isolated \temporary \override without matching \revert in LilyPond. How do you plan to achieve this? If there are any commands using a \temporary...\revert that spans for more than one timestep, I can always nest them and I can always sneak in \overrides between the \temporary and the \revert, just by putting music in parallel. Sneaking is expected to cause problems, and sneaking in _overrides_ is not problematic as they just change the _top_ of the stack, and that gets reverted anyway. Only sneaking in _reverts_ destroys the stack balance, and that means that some states get reverted _more_ than appropriate. However, if the expectation of the user is that they get reverted _totally_ when he writes reverts, things end up better than expected. People have complained about \push/\pop being intolerably programmer-centric _terminology_, but terminology is cheap. The underlying fear was people won't understand what push/pop does, and that can't be cured by using prettier names but only by not doing anything hard to understand unless asked for it. I think stacks are easy to understand, even for non-technical users. The reason for avoiding push/pop is just to stop people from thinking oh, that's programming, it must be hard. Having to keep a stack properly nested _is_ a nuisance. The fundamental complaint about Scheme as the core programming language of LilyPond is that you need to keep so many parentheses nested. LilyPond is _complex_, and sometimes one needs that complexity. But we should try to keep simple things simple, and leave the need to understand complex behavior for when complex things are required. While that's true, I think that a coherent and consistent whole is more important than a slightly simpler beginner interface. I don't find the user interface, as it is, inconsistent. One rarely needs to bother with the full power of a stack (heck, we got along 7 years without a hook into push), and the non-pushing default of \override reflects that. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sun, Oct 14, 2012 at 1:26 PM, David Kastrup d...@gnu.org wrote:
Joe Neeman joenee...@gmail.com writes:
On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup d...@gnu.org wrote:
You are viewing this from the stack angle. But that is a complex
view already. The actual user view is
A.
\override sets a context-specific property value
\revert removes a context-specific property value
This works reliably. If I ever need more complex stuff than that,
I can
look it up.
And to make the this works reliably part work, we won't expose
any
isolated \temporary \override without matching \revert in
LilyPond.
How do you plan to achieve this? If there are any commands using a
\temporary...\revert that spans for more than one timestep, I can
always nest them and I can always sneak in \overrides between the
\temporary and the \revert, just by putting music in parallel.
Sneaking is expected to cause problems, and sneaking in _overrides_ is
not problematic as they just change the _top_ of the stack, and that
gets reverted anyway. Only sneaking in _reverts_ destroys the stack
balance, and that means that some states get reverted _more_ than
appropriate. However, if the expectation of the user is that they get
reverted _totally_ when he writes reverts, things end up better than
expected.
[talk] If you want this to be the user's expectation, then perhaps it would
be more appropriate to have \revert clear the stack entirely. Consider
something like this:
\redNotes { ...
\greenNotes { ...
\override NoteHead.color = #purple
...
\revert NoteHead.color
}
...
}
where the functions redNotes and greenNotes use a push. With the current
behaviour, the note colors will go red, green, purple, red, black, so the
\revert neither undoes a single change nor does it return to the default.
If \revert clears the stack, then you'll get red, green, purple, black,
which is not ideal in my opinion, but at least better than the earlier
option. (My preferred behaviour would be red, green, purple, green, red.)
People have complained about \push/\pop being intolerably
programmer-centric _terminology_, but terminology is cheap. The
underlying fear was people won't understand what push/pop does,
and
that can't be cured by using prettier names but only by not doing
anything hard to understand unless asked for it.
I think stacks are easy to understand, even for non-technical users.
The reason for avoiding push/pop is just to stop people from thinking
oh, that's programming, it must be hard.
Having to keep a stack properly nested _is_ a nuisance. The fundamental
complaint about Scheme as the core programming language of LilyPond is
that you need to keep so many parentheses nested.
An override stack is more forgiving than nested parentheses for two
reasons: first, it isn't an error if you have a non-empty stack at the end
of the piece, and second, there would be a command to clear the stack and
reset the default. It is admittedly hard to know for sure without trying
it, but I find it hard to imagine that keeping track of the stack will
cause difficulties.
LilyPond is _complex_, and sometimes one needs that complexity.
But we
should try to keep simple things simple, and leave the need to
understand complex behavior for when complex things are required.
While that's true, I think that a coherent and consistent whole is
more important than a slightly simpler beginner interface.
I don't find the user interface, as it is, inconsistent. One rarely
needs to bother with the full power of a stack (heck, we got along
7 years without a hook into push), and the non-pushing default of
\override reflects that.
But now that we are giving a hook into push, I think that the non-pushing
default of override will cause problems.
Cheers,
Joe
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Joe Neeman joenee...@gmail.com writes: But now that we are giving a hook into push, I think that the non-pushing default of override will cause problems. I consider it utterly ludicrous that the mere availability of \temporary will magically cause problems with the existing usage of \override, but there is no point in continuing this farce as I have already given up. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Tue, Oct 16, 2012 at 10:21 AM, David Kastrup d...@gnu.org wrote: Joe Neeman joenee...@gmail.com writes: But now that we are giving a hook into push, I think that the non-pushing default of override will cause problems. I consider it utterly ludicrous that the mere availability of \temporary will magically cause problems with the existing usage of \override, Is the example I posted (and which you snipped) utterly ludicrous? but there is no point in continuing this farce as I have already given up. Do you really consider this discussion a farce? I thought I was making reasonable points, but if they are indeed farcical then perhaps I should give up too. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sun, Oct 14, 2012 at 7:56 PM, Phil Holmes m...@philholmes.net wrote: /oneMoment (equivalent to /once, but perhaps a more clear name) modifies a property in the current context for one musical moment. Once the musical moment has passed, the changes introduced by the /oneMoment evaporate. We could apply /oneMoment as a modifier to either /set or /override, or we could just allow it to stand on its own. There is no difference between /oneMoment /set and /oneMoment /override, since the changes evaporate once the moment is gone, so we might as well just to /oneMoment, I think. /oneGrob modifies a property for a single grob (equivalent to /tweak). Its effects are limited to a single graphical object, rather than all objects occurring in this context at this time. I hate these namings. I suggest to use less loaded words, just to make sure that noone will feel offended/attacked. As for the names, i definitely prefer \once to \oneMoment. I don't like \oneGrob. best, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup d...@gnu.org wrote: Trevor Daniels t.dani...@treda.co.uk writes: A. \override does a pop/push \revert does a pop \temporary\override does a push. so \temporary\override and \revert are a matching pair. More importantly: on an empty stack, any number of \override followed by \revert are a matching pair. B \override does a push \revert does a pop \clear restores the stack to the default state. so \override and \revert are a matching pair. Both of these are essentially equivalent, except A does not have a stack clear operation, but which of these is the clearer, and which the more intuitive? You are viewing this from the stack angle. But that is a complex view already. I disagree with this point. I suspect that many of our users are familiar with word processors (probably more so than me) and are perfectly comfortable with the undo stack. I don't see why an override stack is more complicated. The actual user view is A. \override sets a context-specific property value \revert removes a context-specific property value This works reliably. If I ever need more complex stuff than that, I can look it up. I don't find this much more complex: \override sets a context-specific property value \revert undoes the last \override \reset (or whatever) restores lilypond's default. And to make the this works reliably part work, we won't expose any isolated \temporary \override without matching \revert in LilyPond. As I said elsewhere in this thread, I don't see how this is possible to achieve given that we support simultaneous music. People have complained about \push/\pop being intolerably programmer-centric _terminology_, but terminology is cheap. The underlying fear was people won't understand what push/pop does That wasn't my underlying fear. My fear is that users will hear push and pop, think that they mean something complicated, and turn off their brains. Anyway, I don't want you to interpret this argument as being against your patch per se; obviously, it fixes a bunch of real bugs and that's great. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Joe Neeman joenee...@gmail.com writes: 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 There is not really a point in using \undo on single overrides; just use \revert instead. \undo only becomes useful if you don't actually know (or don't want to know, or don't permanently want to tie that knowledge which may become inaccurate with future code changes into your code) the details of what you are undoing. Its main use would be in combination with \temporary, both called on the same complex command. That something like \voiceThree \undo \voiceOne _might_ work (do we get every horizontal shift right?) is not something to rely on, but LilyPond has no way to know that the user is cheating so that it may interfere. It will be the job of the documentation of calling the user names for that. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Reinhold Kainhofer reinh...@fam.tuwien.ac.at writes: On 2012-10-13 23:29, David Kastrup wrote: 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. Sorry, maybe I wasn't clear enough in that last sentence. It would have been clearer if I wrote ... but using the names push and pop ... Well, that is the kind of distinction that just flies over my head without me even noticing: I read code in C, assembly language, Scheme or whatever, and what I read is the story happening in storage and registers, not the names used to express them. The idea that calling commands differently will magically make the underlying concepts disappear is completely alien to me. I don't see programmers will know what this means as an inherent disadvantage: at least somebody gets a headstart. However, programmers will think they know what this means _might_ be a disadvantage. The push/pop naming suffers from the problem that the most basic use of \push does not actually combine it with \pop, but rather with \revert, similar to how \once is much more commonly employed on single explicit \override s rather than on more complex things like \voiceOne. The thing about programming languages was intended to give a larger picture why I don't like pure programming concepts introduced to lilypond users, and using the names push and pop introduces stack concepts to the users, rather than providing a user-friendly (i.e. musician-friendly, not programmer-friendly) high-level API to the users. I am rather skeptical that the naming scheme will be the saving grace here. One will rather need to structure the documentation so that the distinction between advanced concepts (and how to deal with them) and those concepts that are required for even basic use is packaged well. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Joe Neeman wrote Sunday, October 14, 2012 12:14 AM On Sat, Oct 13, 2012 at 2:29 PM, David Kastrup d...@gnu.org wrote: \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. I would be happier with this change. Why not just change the action of \override to be push alone? As its current implementation pretty well ensures all the stacks are empty, changing its action to be push rather than pop+push would have a limited effect on existing scores, wouldn't it? 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. What is clear supposed to be? It empties the stack. 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. That seems a clearer approach (NPI). \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 I think the point is that \undo will never be ostensibly be written with a following \override but rather as \undo \voiceOne. Its action then would be to pop all the \overrides within \voiceOne, returning the state to \voiceThree, \oneVoice, or whatever it was before \voiceOne was called. Even so, if the \undo\override did not exactly match the top of the stack it should throw a warning. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Joe Neeman joenee...@gmail.com 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 depth1 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
Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes: Joe Neeman wrote Sunday, October 14, 2012 12:14 AM On Sat, Oct 13, 2012 at 2:29 PM, David Kastrup d...@gnu.org wrote: \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. I would be happier with this change. Why not just change the action of \override to be push alone? As its current implementation pretty well ensures all the stacks are empty, changing its action to be push rather than pop+push would have a limited effect on existing scores, wouldn't it? Exactly _because_ the current implementation pretty well ensures that all the stacks are empty or close to empty, changing its action to _not_ ensure empty stacks would have a _large_ effect on existing scores. I think the point is that \undo will never be ostensibly be written with a following \override but rather as \undo \voiceOne. Its action then would be to pop all the \overrides within \voiceOne, returning the state to \voiceThree, \oneVoice, or whatever it was before \voiceOne was called. Even so, if the \undo\override did not exactly match the top of the stack it should throw a warning. The warning could only be thrown at the time the music is actually iterated, not at the time the \undo is encountered. That would mean that \undo\override would have to write significantly different data, presumably creating music types of its own. The warning would be generated at an unexpected time of interpretation. I don't really think this is worth the trouble. With issue 2898 URL:http://code.google.com/p/lilypond/issues/detail?id=2898, \undo gets the feature of a _static_ analysis of what it is supposed to be reverting, warning at the time of _call_ when it is clear that it cannot provide something exhaustively countering the property changing effects of the given command. This ensures that \undo provides a command that is fully _suitable_ to be used for countering the given command, and consistent for that. Policing the user about not using the command for anything else would be rather complex to do, and we don't do this kind of thing elsewhere, like enforcing that \oneVoice may only be used after \voiceOne or similar. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup wrote Sunday, October 14, 2012 9:21 AM Trevor Daniels t.dani...@treda.co.uk writes: Joe Neeman wrote Sunday, October 14, 2012 12:14 AM 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. I would be happier with this change. Why not just change the action of \override to be push alone? As its current implementation pretty well ensures all the stacks are empty, changing its action to be push rather than pop+push would have a limited effect on existing scores, wouldn't it? Exactly _because_ the current implementation pretty well ensures that all the stacks are empty or close to empty, changing its action to _not_ ensure empty stacks would have a _large_ effect on existing scores. I'm not so sure. Scores which contain matched \override-\reverts would continue unchanged. Scores which use \voiceOne-\oneVoice would continue unchanged (other than a build-up of stacks, but Joe's suggestion to change \oneVoice to a clear-to-default action would fix that). Scores which contain sequences of \overrides to the same stack would maybe behave differently on a \revert, but how common is that likely to be? People using sequences of \overrides are likely to not use \revert, rather just setting the property to whatever value they want next. But this would cause stack build-up. How serious is that likely to be in practice? (A real not a retorical question.) (I want to pursue this in order to end up with the simplest possible interface consistent with correct behaviour. It will be undeniably harder to explain, and for the users to understand, an interface which provides both the 'flat' implementation and the push/pop implementation. I'd rather ditch the flat one and concentrate on explaining push/pop (maybe using different words) rather than trying to explain both. Whatever reasons Han-Wen had for adopting a flat implementation in 2005 may no longer be valid. We need to consider the optimum implementation suitable for LP as it is today - taking both functionality and understandability into consideration.) I think the point is that \undo will never be ostensibly be written with a following \override but rather as \undo \voiceOne. Its action then would be to pop all the \overrides within \voiceOne, returning the state to \voiceThree, \oneVoice, or whatever it was before \voiceOne was called. Even so, if the \undo\override did not exactly match the top of the stack it should throw a warning. The warning could only be thrown at the time the music is actually iterated, not at the time the \undo is encountered. That would mean that \undo\override would have to write significantly different data, presumably creating music types of its own. The warning would be generated at an unexpected time of interpretation. I don't really think this is worth the trouble. OK, you're probably right, but it will cause surprises. But maybe to no greater extent than other features and only to users who don't inwardly digest the documentation (once written). Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
James, you wrote Sunday, October 14, 2012 12:05 AM I have a patch coming that is trying to at least document \single \hide and \omit. Fine - \hide and \omit are quite straightforward. i also have started to use \single to take the opportunity to better organize NR 5.3. Hhm. This section will need quite a major change once the discussion about \temporary, pop/push, etc has come to a conclusion. Might be better to wait a while. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes: David Kastrup wrote Sunday, October 14, 2012 9:21 AM Trevor Daniels t.dani...@treda.co.uk writes: I would be happier with this change. Why not just change the action of \override to be push alone? As its current implementation pretty well ensures all the stacks are empty, changing its action to be push rather than pop+push would have a limited effect on existing scores, wouldn't it? Exactly _because_ the current implementation pretty well ensures that all the stacks are empty or close to empty, changing its action to _not_ ensure empty stacks would have a _large_ effect on existing scores. I'm not so sure. Well, I did the detective work of tracking down _when_ the change was made (October 2005 by Han-Wen). So there is already a history of LilyPond with this decision made differently. The decision, however little record of its motivation I have been able to dig up beyond the commit itself, was not an accident. There was clearly code added for that exact purpose. Who does not know history is bound to repeat its mistakes. It would appear that we _have_ a history, we don't know it any more, and I suspect we are bound to repeat its mistakes. So I am trying to reverse-engineer the reasons for that decision, and what I arrive at appears plausible to me. And the current discussion appears to match my conclusion, this conclusion being for typical use of these user-level commands, stack-like semantics appear to cause surprises that most normal(TM) users are not well-equipped to deal with. The current programming layer and naming conventions for Scheme programmers are a misleading piece of incoherence, but at the LilyPond user level, a reasonably straightforward non-stack behavior is the default. A stack depth greater than 1 can only be caused by non-user-level code, and that non-user-level should be written in a fashion cleaning up after itself. What \temporary does is provide a LilyPond interface for writing such non-user-level code cleanly. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes: James, you wrote Sunday, October 14, 2012 12:05 AM I have a patch coming that is trying to at least document \single \hide and \omit. Fine - \hide and \omit are quite straightforward. i also have started to use \single to take the opportunity to better organize NR 5.3. Hhm. This section will need quite a major change once the discussion about \temporary, pop/push, etc has come to a conclusion. Might be better to wait a while. If the goal is to never have to write things more than once, the safest way is to wait forever. And I find myself unable to document _this_ in a comprehensible manner, of course, is valid input for design decisions as well. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup wrote Sunday, October 14, 2012 10:56 AM Trevor Daniels t.dani...@treda.co.uk writes: David Kastrup wrote Sunday, October 14, 2012 9:21 AM Trevor Daniels t.dani...@treda.co.uk writes: I would be happier with this change. Why not just change the action of \override to be push alone? As its current implementation pretty well ensures all the stacks are empty, changing its action to be push rather than pop+push would have a limited effect on existing scores, wouldn't it? Exactly _because_ the current implementation pretty well ensures that all the stacks are empty or close to empty, changing its action to _not_ ensure empty stacks would have a _large_ effect on existing scores. I'm not so sure. Well, I did the detective work of tracking down _when_ the change was made (October 2005 by Han-Wen). So there is already a history of LilyPond with this decision made differently. [snip] Well, yes, I know all that. My point is that we don't know the reasons for the decision made in 2005, so we need to consider the best interface for LilyPond _today_, which is markedly different to LilyPond in 2005. I don't think the effect of changing \override to push only would be very dramatic, to either the documentation or in its effect on existing scores. The old version of \override could easily be simulated by prepending a \clear (or \setToDefault or whatever) as Joe suggested if people wanted the current action to continue. In debating this issue we need to consider users writing complex music, rather than songs or one-line melodies - they wouldn't really be affected. Would a proper push/pop action of \override-\revert offer advantages to them without having to use \temporary? I don't know the answer to that as I don't write terribly complex music, although I'd prefer it, as it was the action I expected when I first started using and documenting LilyPond. But if the answer is, No, then I'm content to go along with your \temporary suggestion, and work out a way to document it as effectively as possible. But I'd like to see a few more responses first. To clarify, the two alternative we are discussing are A. \override does a pop/push \revert does a pop \temporary\override does a push. so \temporary\override and \revert are a matching pair. B \override does a push \revert does a pop \clear restores the stack to the default state. so \override and \revert are a matching pair. Both of these are essentially equivalent, except A does not have a stack clear operation, but which of these is the clearer, and which the more intuitive? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes: A. \override does a pop/push \revert does a pop \temporary\override does a push. so \temporary\override and \revert are a matching pair. More importantly: on an empty stack, any number of \override followed by \revert are a matching pair. B \override does a push \revert does a pop \clear restores the stack to the default state. so \override and \revert are a matching pair. Both of these are essentially equivalent, except A does not have a stack clear operation, but which of these is the clearer, and which the more intuitive? You are viewing this from the stack angle. But that is a complex view already. The actual user view is A. \override sets a context-specific property value \revert removes a context-specific property value This works reliably. If I ever need more complex stuff than that, I can look it up. And to make the this works reliably part work, we won't expose any isolated \temporary \override without matching \revert in LilyPond. People have complained about \push/\pop being intolerably programmer-centric _terminology_, but terminology is cheap. The underlying fear was people won't understand what push/pop does, and that can't be cured by using prettier names but only by not doing anything hard to understand unless asked for it. Yes, this makes it slightly more tricky to understand the stack mode of operations. But it will make it much easier to just ignore that view of things completely. LilyPond is _complex_, and sometimes one needs that complexity. But we should try to keep simple things simple, and leave the need to understand complex behavior for when complex things are required. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Two years ago, David and I had a discussion about the existence of /tweak, /set, and /override. David pointed out the confusing nature of the different ways of changing properties, and the difficulty of explaining this to the user. http://lists.gnu.org/archive/html/lilypond-devel/2010-06/msg00054.html Perhaps now David has put together enough infrastructure that it is time to abandon the previous interface and replace it with one that will be more consistent to the user. IIUC, /set and /unset are currently the same as /override and /revert, except they apply to different things: /set and /unset to context properties, and /override and /revert to grob properties. But David has done such good work in allowing the system to determine the target of a call (I suspect that with David's recent patches we have the infrastructure to apply the same call to both context properties and grob properties) that I believe we can drop the distinction. If I'm wrong, please correct me, David. Would it be possible to move to something like the following? /set modifies a property in such a way that no history is kept. /unset (or /reset) returns a property to its default value. /override modifies a property in such a way that a history of the change is stored. /revert undoes the most recent /override of the specified property. /oneMoment (equivalent to /once, but perhaps a more clear name) modifies a property in the current context for one musical moment. Once the musical moment has passed, the changes introduced by the /oneMoment evaporate. We could apply /oneMoment as a modifier to either /set or /override, or we could just allow it to stand on its own. There is no difference between /oneMoment /set and /oneMoment /override, since the changes evaporate once the moment is gone, so we might as well just to /oneMoment, I think. /oneGrob modifies a property for a single grob (equivalent to /tweak). Its effects are limited to a single graphical object, rather than all objects occurring in this context at this time. If we want to move in this direction, I think now is the time to do it (before /temporary gets into the code base). The reason I believe we should do it now is that without /temporary available, convert-ly rules could move all /override to /set and all /revert to /unset or /reset. We don't need to try to parse the /temporary and track the items to which the /revert applies. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Carl Sorensen c_soren...@byu.edu writes: Two years ago, David and I had a discussion about the existence of /tweak, /set, and /override. David pointed out the confusing nature of the different ways of changing properties, and the difficulty of explaining this to the user. http://lists.gnu.org/archive/html/lilypond-devel/2010-06/msg00054.html Perhaps now David has put together enough infrastructure that it is time to abandon the previous interface and replace it with one that will be more consistent to the user. In a nutshell: no. IIUC, /set and /unset are currently the same as /override and /revert, except they apply to different things: /set and /unset to context properties, and /override and /revert to grob properties. But David has done such good work in allowing the system to determine the target of a call (I suspect that with David's recent patches we have the infrastructure to apply the same call to both context properties and grob properties) that I believe we can drop the distinction. If I'm wrong, please correct me, David. You are wrong. Would it be possible to move to something like the following? /set modifies a property in such a way that no history is kept. /unset (or /reset) returns a property to its default value. /override modifies a property in such a way that a history of the change is stored. /revert undoes the most recent /override of the specified property. The data structures for grob properties and context properties are different (grob properties _are_ context properties but have an internal structure of their own). If we want to move in this direction, I think now is the time to do it (before /temporary gets into the code base). Not really. The reason I believe we should do it now is that without /temporary available, convert-ly rules could move all /override to /set and all /revert to /unset or /reset. We don't need to try to parse the /temporary and track the items to which the /revert applies. The effort of changing convert-ly is trivial compared to the required changes in data structure. The property system is on my todo list, but this won't get current before several more months at least. Providing \temporary is not doing any fundamental change. The main problem from the time you described with David pointed out the confusing nature of the different ways of changing properties, and the difficulty of explaining this to the user. is that the documentation explaining the relation of grob properties, context properties and other things is a ridiculous heap of fetid, turgid... Excuse me. We can and must do better than that, and indeed, we are starting with it. At least I more or less _have_ understood the system by now, so I can be of some help to documentation writers. At the time of that discussion, I did not understand the system, and the explanations were not making any more sense either. Yes, it would be nice if all naive assumptions about the system turned out to be true. That's an ultimate goal, but we don't have what it takes right now to get there. But the next best thing is that with a good and thorough explanation, one can figure out what's up. And I think that we are in the situation to work out such an explanation between someone who has a good grasp of explaining things at a nice level, and between some technical savvy people including myself who actually understand what is going on. A well-presented system is not as good as a self-evidently simple system, but it beats what we have now, and I think it is what we can do with reasonable effort. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sun, Oct 14, 2012 at 5:19 AM, David Kastrup d...@gnu.org wrote: You are viewing this from the stack angle. But that is a complex view already. The actual user view is A. \override sets a context-specific property value \revert removes a context-specific property value This works reliably. If I ever need more complex stuff than that, I can look it up. And to make the this works reliably part work, we won't expose any isolated \temporary \override without matching \revert in LilyPond. How do you plan to achieve this? If there are any commands using a \temporary...\revert that spans for more than one timestep, I can always nest them and I can always sneak in \overrides between the \temporary and the \revert, just by putting music in parallel. People have complained about \push/\pop being intolerably programmer-centric _terminology_, but terminology is cheap. The underlying fear was people won't understand what push/pop does, and that can't be cured by using prettier names but only by not doing anything hard to understand unless asked for it. I think stacks are easy to understand, even for non-technical users. The reason for avoiding push/pop is just to stop people from thinking oh, that's programming, it must be hard. LilyPond is _complex_, and sometimes one needs that complexity. But we should try to keep simple things simple, and leave the need to understand complex behavior for when complex things are required. While that's true, I think that a coherent and consistent whole is more important than a slightly simpler beginner interface. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
- Original Message - From: Carl Sorensen c_soren...@byu.edu To: David Kastrup d...@gnu.org; Trevor Daniels t.dani...@treda.co.uk Cc: lilypond-devel@gnu.org Sent: Sunday, October 14, 2012 3:28 PM Subject: Re: Naming _another_ lacking puzzle piece Perhaps now David has put together enough infrastructure that it is time to abandon the previous interface and replace it with one that will be more consistent to the user. I've read David's reply, but am (like Janek) commenting on the principle of how I believe Lily should work, not how immediately possible it will be. IIUC, /set and /unset are currently the same as /override and /revert, except they apply to different things: /set and /unset to context properties, and /override and /revert to grob properties. But David has done such good work in allowing the system to determine the target of a call (I suspect that with David's recent patches we have the infrastructure to apply the same call to both context properties and grob properties) that I believe we can drop the distinction. If I'm wrong, please correct me, David. Would it be possible to move to something like the following? /set modifies a property in such a way that no history is kept. /unset (or /reset) returns a property to its default value. /override modifies a property in such a way that a history of the change is stored. /revert undoes the most recent /override of the specified property. I think this would be a most excellent improvement to usability, if it can be done. I really think both these would be great. In Janek's words: +100 /oneMoment (equivalent to /once, but perhaps a more clear name) modifies a property in the current context for one musical moment. Once the musical moment has passed, the changes introduced by the /oneMoment evaporate. We could apply /oneMoment as a modifier to either /set or /override, or we could just allow it to stand on its own. There is no difference between /oneMoment /set and /oneMoment /override, since the changes evaporate once the moment is gone, so we might as well just to /oneMoment, I think. /oneGrob modifies a property for a single grob (equivalent to /tweak). Its effects are limited to a single graphical object, rather than all objects occurring in this context at this time. I hate these namings. I still struggle with grob, and any musician would think we've gone nuts. I'm not over-happy with oneMoment. I actually think /once works well. As for /tweak: I think tweak is better than oneGrob, and can't think of an improvement at this time. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
2012/10/13 David Kastrup d...@gnu.org:
In ly/music-functions-init.ly I see code like the following:
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
There is a problem with that: in terms of stack operations, \override
and \revert are not opposing pairs: \override is pop+push (so that
multiple overrides in a row don't accrue cruft), \revert is pop. So the
net effect of this sequence is pop, while it should be neutral.
In the Scheme layer, we have the distinction between
make-grob-property-set (corresponding to user command \override, pop+push)
make-grob-property-override (not available as user command, just push)
make-grob-property-revert (corresponding to user command \revert, just pop)
So we need something like
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\temporary\override Stem #'cross-staff = #cross-staff-connect
\temporary\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
and, as a corrollary, \temporary\whatever and \undo\whatever will be a
proper push/pop pair.
Now I find \temporary a fitting name. It is just a bit cumbersome to
type. \interim is hardly shorter, \adhoc seems a bit less descriptive.
Opinions? It might also be possible to do
\temporary { \override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag }
$notes
and have this apply matching push/pop pairs around $notes. It certainly
would at least cater for the most common need of a non-first-popping
push. Perhaps we don't need both (at the current point of time, we
don't have either, and the naming is inconsistent with
make-grob-property-*), but as the crossStaff example shows, we need at
least one of those options.
as a programmer I want a single push and wouldn't mind if pop+push
were two operations; I can't tell what a musician wants.
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Werner LEMBERG w...@gnu.org writes:
So we need something like
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\temporary\override Stem #'cross-staff = #cross-staff-connect
\temporary\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
and, as a corrollary, \temporary\whatever and \undo\whatever will be a
proper push/pop pair.
I like the name \temporary. Is this of practical use outside of music
functions also?
The main point is to restore to a previous state after a temporary
override. This is of course also useful in music assigned to music
variables. In the context of a larger music piece, you can, of course,
just repeat any previous overrides that you want to see reestablished,
but this is not cutpaste friendly.
Maybe \push\override ... but this has the disadvantage that you never
actively see a \pop. Hm. Maybe we should rename \undo to \pop then?
Opinions? It might also be possible to do
\temporary { \override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag }
$notes
I like that too.
It is less versatile, though.
What about
\push { Stem.cross-staff = #cross-staff-connect
Flag.style = #'no-flag }
$notes
\pop { Stem.cross-staff
Flag.style }
[I'm using the `.' operator creatively; no idea whether this works,
and no need to discuss this in case it doesn't :-)]
It doesn't. And I don't even have an awfully twisted idea how to beat
LilyPond into supporting this in any meaningful manner.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
I like the name \temporary. Is this of practical use outside of music functions also? The main point is to restore to a previous state after a temporary override. This is of course also useful in music assigned to music variables. In the context of a larger music piece, you can, of course, just repeat any previous overrides that you want to see reestablished, but this is not cutpaste friendly. OK, for music functions and variable assignments. Then, I think, \temporary is indeed just fine. Maybe \push\override ... but this has the disadvantage that you never actively see a \pop. Hm. Maybe we should rename \undo to \pop then? I think that we either need a consistent use if \push and \pop, or we should refrain using it. Given that the Scheme functions handling the stack are not mapped one-to-one to user commands, as you've shown in a previous mail, I think we should avoid \push and \pop. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Werner LEMBERG w...@gnu.org writes: I like the name \temporary. Is this of practical use outside of music functions also? The main point is to restore to a previous state after a temporary override. This is of course also useful in music assigned to music variables. In the context of a larger music piece, you can, of course, just repeat any previous overrides that you want to see reestablished, but this is not cutpaste friendly. OK, for music functions and variable assignments. Then, I think, \temporary is indeed just fine. Maybe \push\override ... but this has the disadvantage that you never actively see a \pop. Hm. Maybe we should rename \undo to \pop then? I think that we either need a consistent use if \push and \pop, or we should refrain using it. Given that the Scheme functions handling the stack are not mapped one-to-one to user commands, as you've shown in a previous mail, I think we should avoid \push and \pop. The point is that it feels natural to use \push \some-override-sequence \pop \some-override-sequence in pairs, and both \push and \pop could complain if \some-override-sequence contained something unsuitable for complete reversal. And indeed, if I write \omit Accidental cis dis cis dis \pop\omit Accidental this looks ugly and not properly matched, and it _is_ not properly matched. If there was a non-standard stencil set in that context previously, it is gone. So maybe \pop (complemented by \push) is indeed a better name than \undo. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup wrote Saturday, October 13, 2012 1:01 AM
In ly/music-functions-init.ly I see code like the following:
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
There is a problem with that: in terms of stack operations, \override
and \revert are not opposing pairs: \override is pop+push (so that
multiple overrides in a row don't accrue cruft), \revert is pop. So the
net effect of this sequence is pop, while it should be neutral.
What would be the effect of this? The implication is that something
goes wrong, but bugs in this area have never been reported, AFAIK.
I understand stacks, pop and push, but I'm clearly missing something
here. Perhaps it's due to my unfamiliarity with the structure of the
stack(s).
Trevor
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Saturday, October 13, 2012 1:01 AM
In ly/music-functions-init.ly I see code like the following:
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
There is a problem with that: in terms of stack operations, \override
and \revert are not opposing pairs: \override is pop+push (so that
multiple overrides in a row don't accrue cruft), \revert is pop. So the
net effect of this sequence is pop, while it should be neutral.
What would be the effect of this? The implication is that something
goes wrong, but bugs in this area have never been reported, AFAIK.
I understand stacks, pop and push, but I'm clearly missing something
here. Perhaps it's due to my unfamiliarity with the structure of the
stack(s).
Each context has its own stack, so popping too much only makes a
difference if the stack actually was non-empty to start with.
Check out
\new Staff \with { autoBeaming = ##f }
{ \override Flag #'style = #'mensural c8 c \crossStaff c c c c c c }
After the crossStaff, the flag style has reverted to normal again rather
than mensural.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
[...] if I write \omit Accidental cis dis cis dis \pop\omit Accidental this looks ugly and not properly matched, and it _is_ not properly matched. If there was a non-standard stencil set in that context previously, it is gone. So maybe \pop (complemented by \push) is indeed a better name than \undo. But `push' means `to put something on the stack'. Having \omit Accidental however, does exactly the opposite, this is, it *removes* something (well, it pushes the `omit' property, so to say, but this can become very irritating if it gets more complicated). For this particular reason I prefer \undo for the example you've given above. 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. Maybe it makes sense to map the corresponding Scheme functions anew to `simpler' lilypond commands which do less but in a more consistent manner. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Werner LEMBERG w...@gnu.org writes: [...] if I write \omit Accidental cis dis cis dis \pop\omit Accidental this looks ugly and not properly matched, and it _is_ not properly matched. If there was a non-standard stencil set in that context previously, it is gone. So maybe \pop (complemented by \push) is indeed a better name than \undo. But `push' means `to put something on the stack'. Having \omit Accidental however, does exactly the opposite, this is, it *removes* something Uh no, it doesn't. It pushed a ##f property to the stack of Accidental.stencil. (well, it pushes the `omit' property, so to say, but this can become very irritating if it gets more complicated). For this particular reason I prefer \undo for the example you've given above. 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. Well, at least the \grob/\on/\tweakGrob things are tabled again. Changing \override Accidental color = #red to \override Accidental.color = #red and related changes make _those_ abominations redundant. Maybe it makes sense to map the corresponding Scheme functions anew to `simpler' lilypond commands which do less but in a more consistent manner. \once \push \pop \tweak \single _are_ rather minimal and do a single job each. \once changes overriding music into a push/pop pair, \push into push sequences, \pop into pop sequences, \tweak directly manipulates a grob, \single converts overriding music into a \tweak. The rest is tabled after discussion. \omit can be either tweak or override, depending on its last argument, same with \hide, same with \footnote. Just because this is a long discussion covering a lot of ground (and throwing stuff out again) does not mean that the _results_ are bad. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
- Original Message -
From: David Kastrup d...@gnu.org
To: Trevor Daniels t.dani...@treda.co.uk
Cc: lilypond-devel@gnu.org
Sent: Saturday, October 13, 2012 11:25 AM
Subject: Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Saturday, October 13, 2012 1:01 AM
In ly/music-functions-init.ly I see code like the following:
crossStaff =
#(define-music-function (parser location notes) (ly:music?)
(_i Create cross-staff stems)
#{
\override Stem #'cross-staff = #cross-staff-connect
\override Flag #'style = #'no-flag
$notes
\revert Stem #'cross-staff
\revert Flag #'style
#})
There is a problem with that: in terms of stack operations, \override
and \revert are not opposing pairs: \override is pop+push (so that
multiple overrides in a row don't accrue cruft), \revert is pop. So the
net effect of this sequence is pop, while it should be neutral.
What would be the effect of this? The implication is that something
goes wrong, but bugs in this area have never been reported, AFAIK.
I understand stacks, pop and push, but I'm clearly missing something
here. Perhaps it's due to my unfamiliarity with the structure of the
stack(s).
Each context has its own stack, so popping too much only makes a
difference if the stack actually was non-empty to start with.
Check out
\new Staff \with { autoBeaming = ##f }
{ \override Flag #'style = #'mensural c8 c \crossStaff c c c c c c }
After the crossStaff, the flag style has reverted to normal again rather
than mensural.
--
David Kastrup
Surely this points to the pop operation in \override as being at fault? If
\override was simply push, rather than pop-push then the code above would
seem to work as intended.
The further implication of \override being pop-push would seem to be that if
you do something like (pseudo code):
{\override Flag style = mensural c8 c c c \override Flag color = red c c c
c}
Then you'd revert the mensural style when you change the color? That would
be wholly unexpected to me.
--
Phil Holmes
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Phil Holmes m...@philholmes.net writes:
Surely this points to the pop operation in \override as being at
fault? If \override was simply push, rather than pop-push then the
code above would seem to work as intended.
Sure. The idea presumably was not to have stack buildup from things
like
\voiceOne c c \voiceTwo d d \voiceThree c c
The further implication of \override being pop-push would seem to be
that if you do something like (pseudo code):
{\override Flag style = mensural c8 c c c \override Flag color = red c
c c c}
Then you'd revert the mensural style when you change the color? That
would be wholly unexpected to me.
No, each property has its own stack.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup d...@gnu.org writes: Phil Holmes m...@philholmes.net writes: Surely this points to the pop operation in \override as being at fault? If \override was simply push, rather than pop-push then the code above would seem to work as intended. Sure. The idea presumably was not to have stack buildup from things like \voiceOne c c \voiceTwo d d \voiceThree c c It would appear that this behavior was implemented in lily/parser.yy with commit 39dd20959c8b3a143cfe41138a5c62749da54079 Author: Han-Wen Nienhuys han...@xs4all.nl Date: Mon Oct 17 00:04:45 2005 + * input/regression/override-nest.ly: new file. * python/convertrules.py (FatalConversionError.subber): conversion rule for #'callbacks * input/regression/override-nest.ly: new function. * lily/parser.yy (music_property_def): allow \override #'a #'b = #c too. * lily/context-property.cc (lookup_nested_property): new function. (evict_from_alist): new function. (general_pushpop_property): new function. (execute_general_pushpop_property): rewrite. Support nested properties too. There is no rationale for this change to be found in the patch, patch description or changelog entry. There is no rationale to be found on the developer list close to that date. But while searching there, finding URL:http://lists.gnu.org/archive/html/lilypond-devel/2005-10/msg4.html was amusing. Some things stay the same all over. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On 2012-10-13 09:32, Werner LEMBERG wrote: Maybe \push\override ... but this has the disadvantage that you never actively see a \pop. Hm. Maybe we should rename \undo to \pop then? I think that we either need a consistent use if \push and \pop, or we should refrain using it. Given that the Scheme functions handling the stack are not mapped one-to-one to user commands, as you've shown in a previous mail, I think we should avoid \push and \pop. 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. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sat, Oct 13, 2012 at 8:15 AM, David Kastrup d...@gnu.org wrote: David Nalesnik david.nales...@gmail.com writes: Buildup of unwanted data or no, it would be useful to be able to write something like \toLast Accidental #'color to restore the previous override But which is the previous override if you have several in a row? I see your point. I simply meant the immediately preceding override. So: \override Accidental color = #green \override Accidental color = #red \override Accidental color = #blue [...] \toLast Accidental color would restore red -David ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup d...@gnu.org writes: Reinhold Kainhofer reinh...@fam.tuwien.ac.at writes: On 2012-10-13 09:32, Werner LEMBERG wrote: Maybe \push\override ... but this has the disadvantage that you never actively see a \pop. Hm. Maybe we should rename \undo to \pop then? I think that we either need a consistent use if \push and \pop, or we should refrain using it. Given that the Scheme functions handling the stack are not mapped one-to-one to user commands, as you've shown in a previous mail, I think we should avoid \push and \pop. To me it is not only this inconsitency, but rather that the names push/pop come from programming languages and concepts. Uh, that is because they are a plastic visualization here? Lately, I have seen many suggestions that would turn lilypond more into a programming language and away from being a description of music. Reality check: LilyPond already _has_ stacks for properties. Nobody forces you to use any of the new commands if you don't care for stuff working in a better organized manner than flat variables would give you. One can call \push and \pop instead \temporary and \undo, but who are you going to do a favor with that? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Nalesnik david.nales...@gmail.com writes: On Sat, Oct 13, 2012 at 8:15 AM, David Kastrup d...@gnu.org wrote: David Nalesnik david.nales...@gmail.com writes: Buildup of unwanted data or no, it would be useful to be able to write something like \toLast Accidental #'color to restore the previous override But which is the previous override if you have several in a row? I see your point. I simply meant the immediately preceding override. So: \override Accidental color = #green \override Accidental color = #red \override Accidental color = #blue [...] \toLast Accidental color would restore red \override Accidental color = #green \override Accidental color = #red \push\override Accidental color = #blue [...] \revert Accidental color or, if you prefer \override Accidental color = #green \override Accidental color = #red \temporary\override Accidental color = #blue [...] \revert Accidental color \revert will go back to the value before the last \temporary/push override. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Nalesnik david.nales...@gmail.com writes: On Sat, Oct 13, 2012 at 8:29 AM, David Kastrup d...@gnu.org wrote: [...] \override Accidental color = #green \override Accidental color = #red \push\override Accidental color = #blue [...] \revert Accidental color or, if you prefer \override Accidental color = #green \override Accidental color = #red \temporary\override Accidental color = #blue [...] \revert Accidental color \revert will go back to the value before the last \temporary/push override. OK, I see, I'm definitely a fan of \temporary here. Well, if it makes people happier, we'll use \temporary/\undo instead of \push/\pop. Since one can pair \temporary not just with \undo but also with plain \revert, it might look less unbalanced. It is more typing, though. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Janek Warchoł janek.lilyp...@gmail.com writes: On Sat, Oct 13, 2012 at 2:01 AM, David Kastrup d...@gnu.org wrote: There is a problem with that: in terms of stack operations, \override and \revert are not opposing pairs: \override is pop+push (so that multiple overrides in a row don't accrue cruft), \revert is pop. So the net effect of this sequence is pop, while it should be neutral. This looks strange indeed. I've skimmed this thread, but haven't found an answer to this question: would it hurt us really much to have multiple overrides accumulate cruft? I suppose that in real-life situation there won't be that much cruft accumulated - but i might be completely wrong. \voiceTwo \voiceOne \oneVoice Would you expect that after this sequence, the state is like just after \voiceTwo? 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). You can't call functionality without an interface. A prefix like \temporary is better than a full new interface. It's really totally unrewarding to do this kind of work. Instead of Great, finally we get a tool for doing x in a straightforward way, everybody is always hollering oh no, not another tool. Can't we just live with the deficient state? Have you ever tried working with a combined hammer, tongs, screwdriver, drill multi-tool? If you have, you'd value a clean, sorted toolbox with simple and separate tools that all do just one job, and do it well. Again: if you don't _care_ about breaking things, then _don't_ learn how to avoid it, and you will be just fine. Me, I am annoyed at broken things. So I want to have the tools available that help me deal with that. But people are free to ignore that offer. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM As for command names, i'd prefer not to name them \pop and \push as this doesn't say anything to non-programmers. To put it differently: i'd prefer to solve this problem in a way that doesn't require *creating new push and pop commands*. But i have no idea if this is possible. 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. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes: Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM As for command names, i'd prefer not to name them \pop and \push as this doesn't say anything to non-programmers. To put it differently: i'd prefer to solve this problem in a way that doesn't require *creating new push and pop commands*. But i have no idea if this is possible. 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. No user is required to read the source to \crossStaff or \harmonicByFret. That feat is entirely voluntary, and there is no guarantee that doing so is safe from damaging mind and body. Users get quite confused enough with just \override, \revert, \set, \unset and \tweak. We're going too far in this direction now. We are going _nowhere_. We already are _there_. If people say they don't want to switch on the light, I am fine with that. It saves me work to ignore problems and tools in user documentation. But it does not make sense to keep the tools away from people working on LilyPond itself and say please don't provide simple, easy to use tools for fixing bugs which no one has ever noticed. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup d...@gnu.org writes: It would appear that this behavior was implemented in lily/parser.yy with commit 39dd20959c8b3a143cfe41138a5c62749da54079 Author: Han-Wen Nienhuys han...@xs4all.nl Date: Mon Oct 17 00:04:45 2005 + * input/regression/override-nest.ly: new file. * python/convertrules.py (FatalConversionError.subber): conversion rule for #'callbacks * input/regression/override-nest.ly: new function. * lily/parser.yy (music_property_def): allow \override #'a #'b = #c too. * lily/context-property.cc (lookup_nested_property): new function. (evict_from_alist): new function. (general_pushpop_property): new function. (execute_general_pushpop_property): rewrite. Support nested properties too. There is no rationale for this change to be found in the patch, patch description or changelog entry. There is no rationale to be found on the developer list close to that date. And I am learning the hard way why doing things in that stealthy manner is the smart way. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David, you wrote Saturday, October 13, 2012 4:26 PM Trevor Daniels t.dani...@treda.co.uk writes: Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM As for command names, i'd prefer not to name them \pop and \push as this doesn't say anything to non-programmers. To put it differently: i'd prefer to solve this problem in a way that doesn't require *creating new push and pop commands*. But i have no idea if this is possible. 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. No user is required to read the source to \crossStaff or \harmonicByFret. That feat is entirely voluntary, and there is no guarantee that doing so is safe from damaging mind and body. I don't understand. Are you suggesting we should not document these new functions? If so, what is the set of commands which should be documented? Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Trevor Daniels t.dani...@treda.co.uk writes: David, you wrote Saturday, October 13, 2012 4:26 PM Trevor Daniels t.dani...@treda.co.uk writes: Janek Warchoł wrote Saturday, October 13, 2012 3:46 PM As for command names, i'd prefer not to name them \pop and \push as this doesn't say anything to non-programmers. To put it differently: i'd prefer to solve this problem in a way that doesn't require *creating new push and pop commands*. But i have no idea if this is possible. 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. No user is required to read the source to \crossStaff or \harmonicByFret. That feat is entirely voluntary, and there is no guarantee that doing so is safe from damaging mind and body. I don't understand. Are you suggesting we should not document these new functions? If so, what is the set of commands which should be documented? I am not suggesting that. But there is public consent that documenting them would be harmful to our users. I recommend you do a poll to find out which commands the users should be spared from knowing about. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On 12-10-13 10:23 AM, David Kastrup wrote: Trevor Daniels t.dani...@treda.co.uk writes: David, you wrote Saturday, October 13, 2012 4:26 PM Trevor Daniels t.dani...@treda.co.uk writes: 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. No user is required to read the source to \crossStaff or \harmonicByFret. That feat is entirely voluntary, and there is no guarantee that doing so is safe from damaging mind and body. I don't understand. Are you suggesting we should not document these new functions? If so, what is the set of commands which should be documented? I am not suggesting that. But there is public consent that documenting them would be harmful to our users. I recommend you do a poll to find out which commands the users should be spared from knowing about. I wonder if David and Trevor are talking about the same commands here: David brought up the example of reading the source of \crossStaff while Trevor seems to be referring to \override, \tweak et al. FWIW, an uneducated bystander such as I agrees with David’s (implied) position: \crossStaff is a black box, and I only need to know what to put in for an expected output. Trevor raises (or at least, seems to me that he does) the diligent and wise caution that this whole set of paired functions will best be served by some well-organised carpentry in NR at least and probably at least passing mention in LM. Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup dak at gnu.org writes: Trevor Daniels t.daniels at treda.co.uk writes: I don't understand. Are you suggesting we should not document these new functions? If so, what is the set of commands which should be documented? I am not suggesting that. But there is public consent that documenting them would be harmful to our users. So we should Track the bug in \crossStaff and \harmonicByFret Repair these 2 music functions by using the correct push/pop Scheme functions Improve the naming of the make-grob-property-* In general, make more of the Scheme layer documented and accessible *after* seeing a cases where it is useful. I looked for a case in my scores where I wanted a stack, where I wanted to temporarily override something that I had already overridden, and then put back my first override. I did not find any. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Keith OHara k-ohara5...@oco.net writes: David Kastrup dak at gnu.org writes: Trevor Daniels t.daniels at treda.co.uk writes: I don't understand. Are you suggesting we should not document these new functions? If so, what is the set of commands which should be documented? I am not suggesting that. But there is public consent that documenting them would be harmful to our users. So we should Track the bug in \crossStaff and \harmonicByFret Repair these 2 music functions by using the correct push/pop Scheme functions Improve the naming of the make-grob-property-* In general, make more of the Scheme layer documented and accessible *after* seeing a cases where it is useful. I looked for a case in my scores where I wanted a stack, where I wanted to temporarily override something that I had already overridden, and then put back my first override. I did not find any. It's basically the same use case as \once\override except that the temporary change lasts for more than a single timestep. You can always re-override to the preexisting value _iff_ you know it. For input intended to be reused, knowing it is not always possible. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
RE: Naming _another_ lacking puzzle piece
Keith OHara k-ohara5...@oco.net writes: I looked for a case in my scores where I wanted a stack, where I wanted to temporarily override something that I had already overridden, and then put back my first override. I did not find any. I love having the ability to write a music function that will set desired properties, and then put them back to their original state. For example, suppose I want to write a function that emphasizes the notes in the music argument by making all the noteheads red. But it should only apply to the music argument. Then, I want to set things back to what they were when the function exits. If I use revert, it will set the note heads back to black. But if I call the function from a voice that has green note heads, it won't set them back to green; it will always set them back to black. For a couple of years, I've wanted to have the ability to easily do a push/pop pair for use in writing music functions. I'm excited about this option, and fully support it. Thanks, David! Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sat, Oct 13, 2012 at 5:07 PM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: would it hurt us really much to have multiple overrides accumulate cruft? I suppose that in real-life situation there won't be that much cruft accumulated - but i might be completely wrong. \voiceTwo \voiceOne \oneVoice Would you expect that after this sequence, the state is like just after \voiceTwo? Good point. 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). You can't call functionality without an interface. A prefix like \temporary is better than a full new interface. It's really totally unrewarding to do this kind of work. Instead of Great, finally we get a tool for doing x in a straightforward way, everybody is always hollering oh no, not another tool. Can't we just live with the deficient state? Have you ever tried working with a combined hammer, tongs, screwdriver, drill multi-tool? If you have, you'd value a clean, sorted toolbox with simple and separate tools that all do just one job, and do it well. Again: if you don't _care_ about breaking things, then _don't_ learn how to avoid it, and you will be just fine. Me, I am annoyed at broken things. So I want to have the tools available that help me deal with that. But people are free to ignore that offer. David, from your reaction i deduce that you felt attacked by me. I'm sorry as this wasn't my intent. I want to have this situation explained as soon as possible. Please, choose any voip software you like (i understand that you don't want a gmail account nor skype account because of their privacy policy) which can run on Ubuntu, and let's have a voice chat, ok? I can be online tomorrow 9-22 your time. worried Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Janek Warchoł janek.lilyp...@gmail.com writes: On Sat, Oct 13, 2012 at 5:07 PM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: would it hurt us really much to have multiple overrides accumulate cruft? I suppose that in real-life situation there won't be that much cruft accumulated - but i might be completely wrong. \voiceTwo \voiceOne \oneVoice Would you expect that after this sequence, the state is like just after \voiceTwo? Good point. 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). You can't call functionality without an interface. A prefix like \temporary is better than a full new interface. It's really totally unrewarding to do this kind of work. Instead of Great, finally we get a tool for doing x in a straightforward way, everybody is always hollering oh no, not another tool. Can't we just live with the deficient state? Have you ever tried working with a combined hammer, tongs, screwdriver, drill multi-tool? If you have, you'd value a clean, sorted toolbox with simple and separate tools that all do just one job, and do it well. Again: if you don't _care_ about breaking things, then _don't_ learn how to avoid it, and you will be just fine. Me, I am annoyed at broken things. So I want to have the tools available that help me deal with that. But people are free to ignore that offer. David, from your reaction i deduce that you felt attacked by me. No. I am just pissed at the people clamoring for more ignorance, more bugs, and less control. Nobody keeps them from staying ignorant and not taking control. It is their own business, and they are welcome to it, it remains a perfectly available and feasible option, but that does not mean that everybody else needs to be forced to do the same, and it is not like they suffer immensely when the tools they don't want to hear about get used to remove bugs they don't want to be bothered with. People have all the right to their personal choices, but that does not mean that each choice of them makes me equally enthusiastic. I'm sorry as this wasn't my intent. I want to have this situation explained as soon as possible. Janek, with all due respect: I just don't have the time and energy to talk two hours on the phone whenever something happens to annoy me. I get little enough done as it is, and being kept away from actually useful work by repeating what I already wrote makes things more rather than less frustrating. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup d...@gnu.org 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, while Werner was complaining that the plethora of new context-manipulation functions have become confusing. I interpret his comments as a request for orthogonalization rather than a complaint about the options that the new commands introduce. 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. 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. 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. 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 and it lets \temporary be a shortcut for \override ... \undo \override. Since override is non-destructive, we could even get fancy and let \override Something #'color = #green \override Something #'color = #red \undo\override Something #'color = #green go back to the pre-green color. Cheers, Joe ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Joe Neeman joenee...@gmail.com writes: On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup d...@gnu.org 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. 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. \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? I also think that undo
Re: Naming _another_ lacking puzzle piece
On 2012-10-13 23:29, David Kastrup wrote: 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. Sorry, maybe I wasn't clear enough in that last sentence. It would have been clearer if I wrote ... but using the names push and pop ... The thing about programming languages was intended to give a larger picture why I don't like pure programming concepts introduced to lilypond users, and using the names push and pop introduces stack concepts to the users, rather than providing a user-friendly (i.e. musician-friendly, not programmer-friendly) high-level API to the users. Cheers, Reinhold -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com * Financial Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
David Kastrup wrote Saturday, October 13, 2012 10:29 PM I wrote 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. 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. There is no doubt that explaining these concepts to musicians with no experience of programming will be difficult, and at the moment it seems no one is interested in writing documentation except me. I felt I was being forced into having to tackle this problem when I believed (and still believe) that most users have been and would continue to be quite unaware of the difficulties these extra commands are designed to solve. As a programmer myself I fully understand what you are doing; and I'm quite happy with that. So I shall have to find some way of documenting them so that non-programming users will not find learning LP even more difficult than they currently do. That was the basis of my concern. I'll sleep on it. Trevor ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
I completely agree that we need a function that changes a property in a non-destructive way. Me too, in case there was ever a doubt about this. If we were to completely re-design the lilypond language, I would suggest \override, \revert and \clear (as push, pop and clear stack), but they currently have a slightly different meaning. Yes! This is what I wanted to point out, apparently with bad wording which made David think into the wrong direction. The real problems we currently have are [...] Thanks for this! I fully agree with all your reasoning. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
Trevor On 13 October 2012 23:56, Trevor Daniels t.dani...@treda.co.uk wrote: David Kastrup wrote Saturday, October 13, 2012 10:29 PM I wrote 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. 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. There is no doubt that explaining these concepts to musicians with no experience of programming will be difficult, and at the moment it seems no one is interested in writing documentation except me. I felt I was being forced into having to tackle this problem when I believed (and still believe) that most users have been and would continue to be quite unaware of the difficulties these extra commands are designed to solve. As a programmer myself I fully understand what you are doing; and I'm quite happy with that. So I shall have to find some way of documenting them so that non-programming users will not find learning LP even more difficult than they currently do. That was the basis of my concern. I'll sleep on it. I have a patch coming that is trying to at least document \single \hide and \omit. i also have started to use \single to take the opportunity to better organize NR 5.3. I will post what I have tomorrow late afternoon - as 'needs work' as I have explained to David, that I have a bit of a grasp on these subtleties but am not a programmer to know how to articulate these important functions to non-programmers. Examples, at least _good_ examples of @lilyponds are what helps. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Naming _another_ lacking puzzle piece
On Sat, Oct 13, 2012 at 2:29 PM, David Kastrup d...@gnu.org wrote: Joe Neeman joenee...@gmail.com writes: On Sat, Oct 13, 2012 at 1:06 PM, David Kastrup d...@gnu.org 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
