On 2012/10/29 06:20:17, lemzwerg wrote:
LGTM. Nice idea. I'm not sure whether this fits into the large
picture w.r.t.
syntax normalization as envisioned by David, but at least for me it
looks
reasonable.
Well, I replied on the Google code review as well. In a manner, this is the kind of issue that would make it convenient (or at least time- and worry-saving) for me to have the sort of Linus-like dictatorship that the Linux kernel has. With most syntax proposals, "I won't do this myself" is likely enough to let the efforts sizzle out eventually. This is basically the "traditional" approach applied by Han-Wen and Jan, but I don't consider this really an upright way of dealing with things. I have to concede that this approach made them cooperate well (or rather not cooperate, with nobody being particularly unhappy or worried about that) with Graham, something which I failed doing satisfactorily. Now Keith is not as easy to shrug off as that. He delivers code along with his proposals. With regard to syntax changes and/or additions, of course I am the most guilty party for opening cans of worms. Unifying word syntax across modes was perhaps the most disruptive in this area. The result was that "a word is a sequence of letters (including any non-ASCII character by definition), possibly interspersed with single - and _ characters". This is a unification of the word concept that was different in INITIAL and music mode. Now Keith's proposal boils down to "a word is a sequence of letters (including any non-ASCII character by definition) possibly interspersed with single -, . and _ characters, where behind a . there may also come a digit sequence possibly followed by further word constituents optionally starting with -, . and _ again". So far, so bad. Now hooking onto the recent Context.Grob changes probably inspiring this proposal, we have the situation that Context.Grob is equivalent to Context . Grob or to Context . $(string-append "Gr" "ob"), that is, . is acting as an operator here joining several expressions possibly created in different ways. Keith's proposal would not imply that violin . $(+ 1 1) would be the same as violin.2 and not even violin . 2 would work here. The superficial similarity with the dotted syntax breaks down as soon as you try putting it to the test. So in the category "does this change lead to a greater consistency of LilyPond syntax in itself", which is more or less the metric I use for justifying invasive changes to myself, this change introduces complex rules and analogies to existing constructs that work out only at a particular superficial level. It makes LilyPond harder to understand, not simpler. I can wave around my long-term plans which would allow for just writing \violin1 by allowing arrays of violins (I have something in a branch right now, but without further syntax changes I am working on it is not really fitting seamlessly into LilyPond). But long-term plans are not really a suitable excuse for blocking other developers indefinitely. Personally, I consider digits in identifiers not worth screwing LilyPond over. My \"violin1" patch is something I don't consider really a fabulous idea: its main incentive is quieting the demands for more invasive changes that will be quite harder to sort out in its consequences regarding documentation and future changes. It seems that my goal of quieting calls for more invasive changes has actually failed. I expect this to cause a lot of trouble. That is not an absolute counterargument: I expect some of my changes to cause quite a bit of trouble as well. What is, in my book, making a difference in the evaluation is that this trouble, which undoubtedly will tend to end up primarily at my own doorstep, buys us a purely cosmetic change without any functional difference. violin.1 will not be able to have the 1 calculated rather than spelled out. It really just is part of the identifier without numerical meaning. a.b is equivalent to a . b, but a.1 would not be equivalent to a . 1. So while I can't class this is "impossible", I do consider it as "too expensive" in terms of explaining it to the user, and in terms of dealing with followup consequences that will be mostly my responsibility. Now I am perfectly well aware that if "David feels this is a bad idea" is supposed to hold any reasonable amount of power, we are essentially back at a dictatorial situation where I maintain power by virtue of being able to make the most ominous threats (basically, the model of modern representative democracy). Which is, in a way, again cheating our self-chosen systems in a manner I don't appreciate. So I hope that Keith does not view my repeated objections to proposals in this issue as a disregard of his work on them. I hope, pompous as this may sound, that he can view this as a sort of learning situation where his detailed proposals result in more detailed feedback about how the choices in my sort of revolutionary conservatism I tend to exhibit in program design tend to come about. This proposal is clever, and the basic opportunity is well-spotted. I just think it is a bit too clever when we are taking into account the restrictions it still has and the consequences to related areas and the documentation. \"xxx1" has pretty much the same restrictions and underlying ugliness (probably a bit more) and unnecessity. It is just much cheaper and well-confined. It does not have the "this will be a lot of trouble later on" ring to it. http://codereview.appspot.com/6493072/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
