Re: [GLISS] differentiating pre/post/neutral commands

[David Kastrup]

Werner LEMBERG <address@hidden> writes:

>> Rather than proposing something by way of example, I would like to
>> see all proposals in the form of a parser patch that does not
>> introduce extra shift/reduce or reduce/reduce conflicts, and
>> maintains general backward compatibility. If a proposer manages to
>> get that far, I promise I will take a serious look at it.
>
> You are exaggerating, aren't you?  With this prerequisite, very useful
> stuff like `q' would have never been implemented.  It took David a
> long time to generalize it,

Uh, no.  Not "generalize" it.  _Fix_ it.  The implementation was totally
broken and incompatible with LilyPond's normal way of operating (namely,
it did not survive copying of music, and LilyPond copies music in a lot
of situations).  It was a bad hack on top of the parser, based on
assumptions that were invalid.  It became only possible to approach
having it work sensibly when issue 2240 was implemented for different
reasons, because before 2240 there was not even a distinction between
chords and single notes in the music data structure, and without that
distinction, q simply _could_ not work reliably.

> but IMHO it was worth the trouble.

In my opinion, it wasn't.  Just because I found a way to clean up after
people that did not worry about breaking things they don't understand in
return for a modicum of convenience does not mean that this was a good
idea to start with.  We are just now starting to see the tip of the
iceberg of users having to deal with issue 2240.  Bringing LilyPond
input into closer relation with the resulting music expressions (without
changing the resulting stream events) was important for other reasons,
most importantly for being able to work with music functions in the
context of chord elements.

That it brought it into reach to fix the totally broken q was a
side-effect (or rather, its main-effect, but in an area of less
importance) that would, on its own, not have warranted the compatibility
drawbacks of issue 2240.

> Perhaps we should start differently: Instead of making ad-hoc syntax
> suggestions, let's collect experienced user reports about the most
> annoying LilyPond syntax issues.  The stress lies on *user*, not
> developer.  Then parser experts can have a look whether changes are
> possible and useful.

A collection of issues rather than a collection of purported remedies
might indeed make more sense.

As an example, take "I find the need to write something like \violin2".
One remedy is to allow numbers into identifiers.  This can take a large
variety of forms.  Keith's patch is basically a sketch of very specific
form, with advantages and disadvantages not all inherently tied with the
issue as such.

The general issue still has to answer the question "What with \skip4"?
Keith's answer to this particular issue is "only permitted inside of
music", and his answer to "what about top level which currently _is_
music" is "let's make it almost, but not quite, non-music".  And
consequently his implementation of this concept requires meddling with
both lexer and parser and consistency of lexical units.  The details of
this meddling could be improved, but the basic need remains.

So my approach to that issue in general is different, and in particular
to the question "what with \skip4" is "what with it?".  I am for keeping
"\skip4" equivalent to "\skip 4" and, consequently, for keeping
"\violin2" equivalent to "\violin 2" and, by the way, equivalent to
"\violin #(1+1)" as well.  Namely make "\violin" aware that it requires
a number to form a reference.  This does not require meddling with the
lexer, but it certainly requires meddling with the parser.  And, of
course, it opens another can of worms, and it will take quite a bit of
work to smoothen the edges of this can since it is quite a bigger can.
And there is further work pending before it becomes even feasible
opening it.  Which sounds a lot like q actually.

In generally, it is a good idea to move LilyPond in a direction where it
becomes feasible to open a number of cans of worms: it usually means a
robust and flexible direction.  But that does not mean that every can
coming into reach then actually is worth opening, and quite a few are
exclusive, meaning that their opening locks down the possibilities of
future changes again.

-- 
David Kastrup