Graham Percival <gra...@percival-music.ca> writes: > In general, yes. But some aspects of our syntax haven't been > around for a long time -- footnotes, woodwind fingering, compound > meters, etc. Do we have the best syntax for those? I mean, > maybe David can figure out a way to allow us to write > \compoundMeter (3+2)/8 > or simply > \time (3+2)/8 > instead of > \compoundMeter #(3 2 8)
I'd have done so already, but \time takes an optional beatstructure argument that is indistinguishable from a compound meter, being a number list. > Other than indirectly possibly motivating people to work on > converters and GUIs from lilypond code, I don't see GLISS as > adding new features to lilypond at all. Rather, I'm expecting > that new development continues as before; after some syntax has > been around for long enough that we're confident that it's good, > we declare it as "stable" so that users and programmers can rely > on it. Longevity is not a measure for quality. In particular when we are talking undocumented language quirks that are not likely to have been known or exercised. Documenting is a good litmus test: if writing documentation for some peculiarity makes your stomach turn, chances are that declaring it as part of a "stable" set is not doing anybody a favor. >> * dramatically simplify our parser/lexer code in a way that brings >> future rewards. > > David is working on this. Somewhat backwards: I am trying to bring future rewards, and when our current syntax throws a spanner in my works, I try arguing for change by figuring out the sneakiest way to streamline it. > Some of his changes will break user code, and some users will be upset > by this. I'm trying to make users feel better by phrasing it as a > "give and take" situation. Yes, some things will break, but other > things will have a guarantee of stability -- and the area of stability > will increase over time. LilyPond has quite a few areas where the underlying design is of "poke-with-a-stick-until-it-does-one-job" quality, drive-by coding. There is little won to "stabilize" on random stuff that is going to make life harder afterwards and that probably nobody understands or uses extensively. >> * dramatically expand our user-base > > Syntax stability can't hurt converts and GUIs. I hope that GLISS > can indirectly increase our user-base by making it easier for > people to convert music into lilypond. And have a good subset of LilyPond they can expect to convert back. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
