Graham Percival <gra...@percival-music.ca> writes: > At the Waltrop meeting, Janek proposed a number of interesting but > potentially disruptive changes to the lilypond syntax. On a > personal note, I really like most of them, but it will take a good > chunk of work before they're ready to discuss on the main > development list. > > Further complicating issues is that it quickly became apparent > that I am not personally qualified to judge if a proposal is ready > for main discussion.
Wouldn't the purpose of a discussion be to present and discuss advantages and drawbacks? The question of _discussing_ a change is in my opinion quite different from _implementing_ a change. > For example, one idea was to use postfix notation for (almost) > everything. David pointed out that this would wreck havok on music > functions, and I had to admit that I have no clue what a music > function is. I mean, I know that there's \commands, but I have no > clue what the difference is between \p, \relative, \staccato; other > than their effect on the graphical+midi output. Well, this was actually more or less divided into several separate changes. One part was to _enforce_ having to write a directional modifier for postevents, meaning that whenever _ or ^ are allowed, you need to write at least -, like c4-(-[-\p-~ . This would admittedly simplify the parser (and other programs trying to parse LilyPond input), particularly when music functions like \tweak and \displayMusic and event functions like \bendAfter and \rightHandFinger get involved. Another part was to keep the undirectional syntax alive but assign different meaning to it on an as-case basis. With regard to providing a simpler interface to humans and computers, the proposals were somewhat conflicting in their direction, so it would make sense to discuss them separately where this happens to be the case. > I'm not enthusiastic about cluttering -devel with preliminary > discussions like teaching me about music functions vs. whatever the > other thing are. I am not enthusiastic about cluttering -devel with non-preliminary discussions where everybody is assumed to have mastered the topics right from the start. There are reasons and implications for some of the design decisions, and part of the aims of such a discussion is leaving the participants with a better understanding about what is involved than the manual might provide. Frankly, the parser is a mess. Removing some convenience, like what I characterize as part one of his proposal, will provide at least some relief, at the cost of making previous syntax invalid and causing a less natural look of the music expressions. It is already possible to use this part of the syntax proposal as a _convention_. LilyPond just does not enforce it. > At one point there was a mailing list on lilynet for syntax > discussions, but I'm not certain if that's active. I could also make > a new gnu.org mailing list... but either of those options would > require anybody interested in that discussion to sign up for a new > mailing list. > > Thoughts? opinions? alternatives that I haven't considered? > These discussions are going to produce a *lot* of emails. And if they come to conclusions, they are going to produce effects on everybody. Including people using "LilyPond as a service". -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
