Han-Wen Nienhuys <hanw...@gmail.com> writes: > On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival > <gra...@percival-music.ca> wrote: > >> The meta-target is "after spending 5 years very publicly telling >> people *not* to talk about changing the syntax because we would do so >> 'in a year or two', I think I should encourage such discussions.". I >> mean, people trusted me when I said that there > > I have been trying for years on end to dissuade anyone from discussing > or proposing syntax changes.
Well, I am proposing syntax changes on a regular schedule... Most of them don't affect the bulk of existing LilyPond files, while often changing the set of valid files significantly. It is often in the "wait, you mean _this_ was valid LilyPond code before?" area. > Look how successful I was. Whatever you have been saying in the past > is irrelevant. Hardly. We have a continuity of developers and expectations, and that is what Graham has to work with. > I predict that a lot of discussions will be had, and we will end up > with virtually no changes. I guess that such is life. > >> Of course many of our ideas will not be good. That's fine! >> That's how creative thinking works! > > No; syntax discussions without understanding how the lilypond parser > works is just blowing around hot air and discussing bike shed colors. The LilyPond parser toolkit is rather powerful, and one can do a lot with it. Partly by tricking around and doing some things manually when they are definitely worth doing. Most of the proposals are a bad idea without actually having to look at implementability because they introduce ambiguities that are hard to resolve not just in LilyPond's parser (which can be fiddled to be able to do a lot of fine distinctions), but generally in the grammar. Usually when it is hard to teach LilyPond's parser fine distinctions, it means that it is hard teaching its users the fine distinctions as well, and hard to teach convert-ly the fine distinctions, and hard to teach programs writing and reading LilyPond the fine distinctions. And many proposals are of the kind one can't even resolve with fine distinctions since they are inherently contradictory or ambiguous. The problem is not that the parser would not warrant some changes. The problem is that the discussion tends to focus on lines leading nowhere for various reasons, and that causes a state of panic for those actually working on the parser, and frustration for those who feel that their proposals are not taken seriously by those "in power", namely actually working with and on the parser code. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
