Re: Bravura in LilyPond

[David Kastrup]

Janek Warchoł <address@hidden> writes:

> Ok, probably my last lily email for a few days...
>
> 2013/12/22 David Kastrup <address@hidden>:
>> Well, if you take a look at things like
>> <URL:http://code.google.com/p/lilypond/issues/detail?id=3723>, the
>> amount of feedback is, uh, underwhelming.  It focuses on indentation
>> (I have to admit, though, that I had forgotten about Werner expressing
>> his opinion that this is a move in the right direction).
>>
>> Since the patch series _vastly_ simplifies the grammar while extending
>> and regularizing its functionality, this is somewhat amusing.  But then
>> it is not entirely unexpected.
>
> I've looked at it now, but i wasn't able to see how it makes life
> easier for me, so i cannot give any feedback, sorry :(  But i'm sure
> that it makes things better - thanks!

Well, you'll be able to write

\relative \tweak color #red c'4

without getting

/tmp/rob.ly:1:29: error: syntax error, unexpected NOTENAME_PITCH
\relative \tweak color #red 
                            c'4

(and it's rather involved to explain what causes the error).  And the
grammar has been cleaned of several hundred lines, and those lines were
more complex than the much fewer lines they have been replaced with.
That means that you have a better chance to meddle with the parser.

Error messages and point-and-click could be skewed when optional
arguments were involved.  Since the "backup tokens" now carry location
information, this is no longer an issue.

Issue 2067 "Give \displayLilyMusic and \displayMusic optional port
arguments." could finally move forward without causing

\displayLilyMusic \tweak color #red c'4

to fail.  Being able to print to arbitrary ports is definitely useful.

Several past mailing list conversations with Harm along the lines "Can
anybody tell me why this music function definition does not work as
expected" are now moot.

And it's another step towards the goal of just having one kind of
function which is treated differently depending on its return value
rather than its definition, meaning that you will be able to write

c'4 \tweak color #red \pp

instead of

c'4 -\tweak color #red \pp

one day.

For me, the most important things are
a) no need to explain obscure restrictions to users
b) no need to explain complex parser rules and their rationale to
   programmers
c) parser maintenance can realistically be done by people other than me
d) this ends several years of increasing contortions trying to
   compromise between optional argument parsing and complex tentative
   parsing of expressions with minimal lookahead, like issue 3639: its
   rather complex code is gone.

-- 
David Kastrup