Graham Percival <gra...@percival-music.ca> writes: > 1. declare the 2.16.0 syntax absolutely frozen (possibly with the > exception of property names and scheme). Reject absolutely all > patches to lily/parser.yy
That does not make sense as long as we don't have a reasonably coherent starting point for freezing. > 2. have a serious and respectful discussion on lilypond-devel > about these compromises and whether we think it is appropriate to > select a different compromise for some portion(s) of the syntax > given what we've seen from the past 15 years of LilyPond. > > 3. have a serious and respectful discussion on a different list, > and when those discussions reach a firm proposal, bring that > proposal to lilypond-devel for a serious and respectful discussion > about the well-researched proposal. > > > So far I don't feel that the discussion has been very fruitful. And it will not be fruitful in the near future. One reason is that I am basically the only one seriously working on the parser right now, and I am learning while I am working on it, both about the work flow for getting Bison where you want it, and about the complications. This is work that is really hard to do, but it can't be done except, basically, incrementally. Even though the end point is consistent in itself again. And it needs experimentation to find the next incremental step. It is nice to say one should first declare where one wants to be going and only start moving after having finished the plan. But it is not realistic. All in all, this is taking a direction that gives more power and flexibility to the user, while making LilyPond more programmable, and thus even less suitable as a general purpose music representation. But it never _was_ all that suitable. It has almost always been complex to a degree that the only reliable LilyPond parser has been LilyPond itself. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
