Graham Percival <gra...@percival-music.ca> writes: > On Thu, Sep 13, 2012 at 11:39:52PM +0200, David Kastrup wrote: >> Graham Percival <gra...@percival-music.ca> writes: > >> > I think we need to decide what direction we want the syntax to >> > move in (or indeed, decide not to change the syntax at all!). >> >> I don't see the point in the repeated threats of locking me out from >> what I am working on. > > You have a fundamental misunderstanding of these discussions. The > intent is to share ideas, not to bring forward formal proposals for > language modifications.
"decide not to change the syntax at all" means stopping me from working on the parser. I am doing my best within the existing possibilities of staying upwards compatible, but "no change at all" means just that, unwanted side effects and all. >> > Yes, of course a shared project would be much easier with a >> > benevolent dictator. >> >> The only alternative I see so far is a benevolent slave. Nobody is >> working on syntax right now except me. And nobody is interested in >> working on it except me. Instead people are interested in telling me >> what I should be doing. > > You are not a slave. Nobody is telling you what you should be > doing. Nobody is demanding that you take these discussions > seriously -- in fact, I have repeatedly told you *not* to take > them seriously! If you state that one possible goal is to decide no further changes will be allowed, and if statements like "I think we need to decide" are coming from the project leader, it is pretty strange to say I should not be taking them seriously. > Most of the ideas are unworkable from the standpoint of > unambiguous notation of music. If a human can't understand what > the syntax means, then of course a computer can't understand it! But if a human can't understand that he can't understand what the syntax means, he will try to persuade the computer otherwise, and at some point of time, people will have a heap of workarounds to maintain that do not make for a consistent whole. The usual approach in the backend is to heap exceptions upon exceptions until the result is more often than not aesthetically pleasing. And given the problem space, that approach is not, in itself, wrong as long as the infrastructure supports this approach since the overall goal is a complex aesthetic one that is fuzzily defined. This approach does not work with input syntax. Not if we want to give users the tools required for extending LilyPond for their own purposes, and we want to give them the tools since it means that we also get a workforce of people helping with extending and maintaining the version of LilyPond we distribute. The "extend in arbitrary ways to the point of breakage" approach works with a fixed, closed, hard-wired syntax, making LilyPond fixed, closed, and hard-wired. And that is short-selling its capabilities. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel