Graham Percival wrote Tuesday, July 24, 2012 10:09 AM > ** Summary > > Let’s decide whether to try to stabilize the syntax or not.
We /should/ try to stabilize the syntax, but trying to do this at exactly the time when David is straightening out the parser seems a bad idea. As yet we do not know where the parser changes may lead eventually. > ** Stability or not? > > Stabilizing a language is a tricky process. If you do it too > early, then you’re stuck with whatever mistakes or poor design > decisions. Exactly. We should wait until David's parser changes settle out. > 2. Define a subset of input as being stable for the 3.x branch. > We add regression tests for that subset of notation and > forbid running convert-ly on those files. At the moment, I > imagine that the subset would consist of at most Notation > sections 1.1 Pitches, 1.2 Rhythms, and the overall file > organization; nothing else. Changes to input other than that > subset are fine. I'd be happy to see a start being made on this now, in spite of my comments above, but we must delay the actual release of the definitive syntax-stable version until we have confidence the parser changes have stabilized. The task David has set himself is difficult enough without his being hamstrung by a premature release imposing further constraints on the parser. Predicting the effect those constraints might have on the parser is pretty well impossible. Trevor _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
