Re: preliminary GLISS discussions

[Han-Wen Nienhuys]

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.

It would be helpful to have a comprehensive overview of what would be changed.

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. By
itself, I think this change (which would invalidate pretty much all
existing .ly files) does not carry its weight, IMO, but if there is
some awesome side effect, it might be worth considering.

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?

> 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.

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

$ git blame -e parser.yy|awk '{print $3;}'|sort|uniq -c|sort -n
      1 (<address@hidden>
      1 (<address@hidden>
      1 (<address@hidden>
      2 (<address@hidden>
      2 (<address@hidden>
      2 (<address@hidden>
      3 (<address@hidden>
      5 (<address@hidden>
      9 (<address@hidden>
     17 (<address@hidden>
     56 (<address@hidden>
     68 (<address@hidden(none)>
    164 (<address@hidden>
    177 (<address@hidden>
    400 (<address@hidden>
   1214 (<address@hidden>
   1335 (<address@hidden>

>  Removing some convenience, like what I
> characterize as part one of his proposal, will provide at least some
> relief, at the cost of making previous syntax invalid and causing a less
> natural look of the music expressions.  It is already possible to use
> this part of the syntax proposal as a _convention_.  LilyPond just does
> not enforce it.

>> Thoughts?  opinions?  alternatives that I haven't considered?
>> These discussions are going to produce a *lot* of emails.
>
> 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.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen