[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Anybody else with an interest in parser wrangling?

From: John Wheeler
Subject: Re: Anybody else with an interest in parser wrangling?
Date: Mon, 20 Mar 2023 09:06:21 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0

On 3/19/23 11:51, David Kastrup wrote:
I've not been particularly active in the last years, and there has not
really been a significant pickup in activity concerning syntax/parser.
Now for better or worse, before I picked up tenure there was GLISS, the
"Grand Lilypond Input Syntax Something" that sort of tried a top-down
prescription of what syntax would be desirable.

This suffered from a lack of feedback and input, suggestions and
inspiration from the technical/implementation side and led, among other
things, to a lot of churn between myself and the maintainer at that
time, Graham, that ultimately contributed to him releasing the reins of
the project because he figured he wasn't helping.

His organisational talents that fleshed out roles and procedures working
reasonably well with our scattered resources and interests of developers
and documenters and other contributors can still be witnessed in the
LilyPond project's somewhat unique organisational approach for getting
contributions integrated and, to the degree possible, vetted.

But while my desire for work on user-pointing and internal design and
architecture at that time sort of unfolded mostly in a vacuum, the years
since then have not seen a lot of uptake.

For example,

git shortlog -n -s --since '10 years ago' lily/parser.yy

is sort of one-sided (admittedly, with '1 year ago' this looks
different, though removing the -s argument in order to see the details
also makes clear that a lot of work was not syntax related, with not
much more than one minor and one more elaborate addition).

As an example, I am just wrangling with extending user-definable
functions in the parser, and end up with things like reduce/reduce
conflicts that need to get ironed out.  Bison options like
-Wcounterexamples by now help with visualising what goes wrong (in my
time, I used an Emacs Lisp contraption to come up with conflict
examples), but one still needs to come up with plans how to
circumnavigate such obstacles and it usually ends up being an exercise
of trial and error a lot.

There also is a lot of potential for making ping-pong progress.  I
realize that I am not exactly the most fun person to be working with,
but also I tend to get stuck on boring or repetitive tasks to an
inordinate degree.  Of course it is not an inviting process to tackle
those, but someone being slowed down to 20% of their potential will
still easily beat someone being slowed down to 0.2% of their potential
regardless of how impressive or not the respective potentials may look
on paper, or more exactly before doing the gritty work of actually
getting down on paper.

So how to better involve others?  The parser may be one of those areas
with an awful amount of shoestring and glue, namely fiddling around
until things happen to work.  All that fiddling happens in private
before commits end up in master, meaning that it has no opportunity to
end up contagious the way it happens now.

That's not really fabulous regarding the "bus factor" in that area.

When I was becoming familiar with the LilyPond manuals, it seemed
to me one manual that was missing was a concise specification of
the LilyPond language, something paralleling the R5RS for the Scheme
language.  I spend a lot of time studying the lexer.ll/parser.yy code trying
to put together something along those lines for own use.  Right now that
work is stuck at a *rough* draft.

Given that effort, I think I have a fair idea of how the lexer/parser
functions.  I would be happy to contribute in this area.

How can I be of service?

John Wheeler

reply via email to

[Prev in Thread] Current Thread [Next in Thread]