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

[Han-Wen Nienhuys]

On Mon, Sep 3, 2012 at 2:19 AM, David Kastrup <address@hidden> wrote:
>> I predict that a lot of discussions will be had, and we will end up
>> with virtually no changes. I guess that such is life.
>>
>>> Of course many of our ideas will not be good.  That's fine!
>>> That's how creative thinking works!
>>
>> No; syntax discussions without understanding how the lilypond parser
>> works is just blowing around hot air and discussing bike shed colors.
>
> The LilyPond parser toolkit is rather powerful, and one can do a lot
> with it.  Partly by tricking around and doing some things manually when
> they are definitely worth doing.  Most of the proposals are a bad idea
> without actually having to look at implementability because they
> introduce ambiguities that are hard to resolve not just in LilyPond's
> parser (which can be fiddled to be able to do a lot of fine
> distinctions), but generally in the grammar.  Usually when it is hard to
> teach LilyPond's parser fine distinctions, it means that it is hard
> teaching its users the fine distinctions as well, and hard to teach
> convert-ly the fine distinctions, and hard to teach programs writing and
> reading LilyPond the fine distinctions.  And many proposals are of the
> kind one can't even resolve with fine distinctions since they are
> inherently contradictory or ambiguous.

> The problem is not that the parser would not warrant some changes.  The
> problem is that the discussion tends to focus on lines leading nowhere
> for various reasons, and that causes a state of panic for those actually
> working on the parser, and frustration for those who feel that their
> proposals are not taken seriously by those "in power", namely actually
> working with and on the parser code.

I think we are in violent agreement.

I would much rather see patches to the parser rather than proposals
that show examples. Examples always show how things would work in
obvious situations, but the problem is not in the obvious cases. The
problem is in all the ambiguities that have to be resolved. Without
working on the parser, it is difficult to appreciate the subtleties of
specifying a grammar unambiguously and maintaining backward
compatibility.

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.

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