"Trevor Daniels" <t.dani...@treda.co.uk> writes: > 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.
To be fair, it is not likely that David will stop "straightening out the parser" anytime soon. One problem with "straightening out" the parser, however, is that it is very much guided by remaining upwards compatible, and that individual changes breaking upward compatibility are hard to argue on their own merits. So the trend is to resolve ambiguities by adding complexity. That avoids compatibility issues for the time being. However, it means that the same amount of complexity for resolving ambiguities would need to get applied by convert-ly, text editors with syntax support for LilyPond, and tools importing LilyPond, all of which is not realistic. So the price of LilyPond retaining the ability to process almost anything it was able to process before and calling that the de facto standard is that everybody else gives up on LilyPond as a music description language. It also means that the moving target for full anecdotal backward compatibility (try supporting anything that may have worked at some point of time) gets more horrific the longer this goes on. > As yet we do not know where the parser changes may lead eventually. Well, the expectation in the medium range is to solidify on music functions, and have a mechanism where there is just one kind of them, and just one kind of argument parsing. >> ** 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. Again: this is not going to happen anytime soon, and even if we are postulating that I am the only one working on the changes, they need to fit with some direction. At the current point of time, I am more or less factually dictator of the lexer/parser since a statement "this is not doable" from me will go uncontested. But the path of least resistance is a path where lots of mostly historical ambiguities, partly due to arbitrary design choices, get resolved with a considerable involvement of complexity. And defining the whole of what will compile at a current point of time as an archive language does not really work. >> 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. It has to be said that at the current point of time the main challenge in lexer/parser work is in the _lack_ of constraints. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel