Re: preliminary GLISS discussions

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Wed, Aug 29, 2012 at 10:15 AM, David Kastrup <address@hidden> wrote:
>>> For example, one idea was to use postfix notation for (almost)
>>> everything.  David pointed out that this would wreck havok on music
>>> functions, and I had to admit that I have no clue what a music
>>> function is.  I mean, I know that there's \commands, but I have no
>>> clue what the difference is between \p, \relative, \staccato; other
>>> than their effect on the graphical+midi output.
>>
>> Well, this was actually more or less divided into several separate
>> changes.
>>
>> One part was to _enforce_ having to write a directional modifier for
>> postevents, meaning that whenever _ or ^ are allowed, you need to write
>> at least -, like c4-(-[-\p-~ .  This would admittedly simplify the
>> parser (and other programs trying to parse LilyPond input), particularly
>> when music functions like \tweak and \displayMusic and event functions
>> like \bendAfter and \rightHandFinger get involved.
>
> For example, I understand that requiring '-' for every post event
> would simplify the parser. At the same time, it is not clear to me
> what benefit simplifying that part of the parser will bring us.

I am currently working on unifying event functions (of which there are
not many yet, but they are a natural complement to event variables which
can be used without - before them), music functions, and scheme
functions, basically _first_ evaluating the function, _then_ deciding
its type, similar to the way \xxx works.  This is tricky when taking a
look at things like

\displayMusic c \tweak #'color #red c

as opposed to

\displayMusic c \tweak #'color #red \p

since you get the semantic values for making the required decisions in
the syntax rather late.

> Is there a complete proposal of what is on the drawing board? Barring
> that, is there a list of (perceived) problems in the current
> syntax/parser?

The possible values for music following a skipped optional argument are
constrained to music parseable without lookahead because the decision
for skipping requires evaluating the music expression first before
letting the parser change state or pushing back a synthetic token which,
again, is only possible when there is no lookahead token yet.

This is stalling things like
<URL:http://code.google.com/p/lilypond/issues/detail?id=2067> and leads
to behavior surprising to users.

>> Frankly, the parser is a mess.
>
> Jan and me are to blame for that. I think we spent too much time
> musing over syntactic sugar, rather than coming up with less pretty
> but simpler syntax.

Actually, for much of the current mess I am to blame since I retained
most of the shortcuts and prettiness while moving things to music
functions rather than hardwired syntax.  Making those shortcuts a part
of user-writable extensions rather than hardwired into the parser makes
the parser quite more opaque.  The LilyPond notation manual shows the
current LilyPond syntax definition from Bison.  This move to generality
rather than hardwireness makes it a lot less handy and useful as a
reference.

> It is a mess, and that should be clear to anyone who ever worked with
> it. Unfortunately, according to git blame, there are very few such
> persons.  At the end of the day, probably only you and me are
> qualified to judge on proposals from the perspective of parser.yy

And you would likely need a solid bout of catching up.  No question that
you are in an excellent starting position for that, though.

I hope I can get to a state where I can reduce complexity again and/or
compress it into a few dense well-designed places.

> $ git blame -e parser.yy|awk '{print $3;}'|sort|uniq -c|sort -n
[...]
>    1214 (<address@hidden>
>    1335 (<address@hidden>

Oops.

>> And if they come to conclusions, they are going to produce effects on
>> everybody.  Including people using "LilyPond as a service".
>
> Before we go around proposing solutions, it would be good to know what
> problems we are trying to solve.

The focus of Janek, as far as I remember, was people being able to read
valid LilyPond, people being able to write valid LilyPond.  Of course,
there is a large variety of opinions what this entails.

For people like those from Scorio and Philomelos, outside programs being
able to read valid LilyPond and being able to write valid LilyPond is
important, a different consideration.

And I am also somewhat focused on the work it takes to make LilyPond
able to read valid LilyPond...

-- 
David Kastrup