Re: Allow digits in identifiers (issue 6493072)

[dak]

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/