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

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Sat, Sep 1, 2012 at 4:39 PM, Graham Percival
> <address@hidden> wrote:
>
>> The meta-target is "after spending 5 years very publicly telling
>> people *not* to talk about changing the syntax because we would do so
>> 'in a year or two', I think I should encourage such discussions.".  I
>> mean, people trusted me when I said that there
>
> I have been trying for years on end to dissuade anyone from discussing
> or proposing syntax changes.

Well, I am proposing syntax changes on a regular schedule...  Most of
them don't affect the bulk of existing LilyPond files, while often
changing the set of valid files significantly.  It is often in the
"wait, you mean _this_ was valid LilyPond code before?" area.

> Look how successful I was. Whatever you have been saying in the past
> is irrelevant.

Hardly.  We have a continuity of developers and expectations, and that
is what Graham has to work with.

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

-- 
David Kastrup