On Thu, Jul 26, 2012 at 09:02:38AM +0100, Trevor Daniels wrote: > Graham Percival wrote Tuesday, July 24, 2012 10:09 AM > > > 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.
tl;dr: we agree on the actual "what we will do", but disagree on the reasons behind it. :) I actually think that David's work on the parser makes this is the perfect time to do GLISS. - the code should match our desired language specification, not the other way around. Do we want to allow numbers like 0.37 which do not begin with a leading 0? that's not a code question, that's a language question. Of course the language design should be heavily influenced by the implications for the computer implementation (i.e. parser and lexer), so I don't think we would be able to have this discussion without David's expertise on the matter. - straightening out the parser is going to lead to some breakage in (complicated and/or badly written) scores. That may lead to some understandable frustration from some users, but if we're running GLISS at the same time, that gives them some hope that things will settle down. > 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. I agree with delaying the definitive syntax-stable versions; I'm imagining something like a "proposed stable" syntax that must exist for 6 or 12 months without any change or quibbles before it's accepted as "actually stable". - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel