Anybody else with an interest in parser wrangling?

[David Kastrup]

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.

-- 
David Kastrup