Re: Anybody else with an interest in parser wrangling?

[David Kastrup]

David Zelinsky <dsz@dedekind.net> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> 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.
> [...]
>> 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.
> [...]
>> 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.
>
> I've been interested in finding ways I can contribute to Lilypond,
> beyond the couple of minor merge requests I've had accepted.  I don't
> know much about parsers.  I read the dragon book years ago, and have
> written some seat-of-the-pants code that might qualify as parsing, for
> various things related to my math research, but nothing at all
> complicated or formal.  And my experience with, say, bison, is that I've
> heard of it. :) But I'm comfortable reading documentation and happy to
> learn new things.  And I have plenty of experience getting down into the
> weeds fiddling with things to get them to work just right.
>
> So if you're willing to have a bit of patience and point me in the right
> direction to learn things I need to know, I'm happy to help.

Well, I guess the first litmus test is taking a walk crossreading
lily/parser.yy and getting a feeling for what makes sense to you and
what makes your eyes glaze over.

A recent comparatively straightforward change had been

commit 276d688a358ff49e04b8b18e91ac15d56276cb62
Author: Jean Abou Samra <jean@abou-samra.fr>
Date:   Sun Dec 18 18:27:24 2022 +0100

    Accept bare pitches/durations as music arguments to markup commands
    
    This adds a tiny bit of the smart argument handling music functions have to
    markup commands.  Namely, if a command expects a Scheme argument (i.e., the
    predicate is not markup? or markup-list?), and { <pitch> } or { <duration> 
} is
    passed, the music interpretation as note event of those constructs is tried 
as
    well against the predicate.  The most obvious use case is
    
      \markup \rhythm { 8. }

Checking it out may be a hint about what a "comfort level" change not
involving an inordinate amount of shoestring and glue would like.

Probably the worst shoestring and glue department is how
function_arglist is destructured.

I may add some work-in-progress stuff to a branch soonish.  I currently
have implemented the equivalent of define-music-function for pitches and
am mostly through with duration function (I am stuck on 4 reduce/reduce
conflicts at the moment that are essentially all the same problem).
This would warrant extending to book functions, score functions and a
few others.  Most of those are likely trivial to do and don't offer a
lot (other than consistency and syntactic predictability) over
define-scheme-function.

So there are some candidates which are easy to implement in that
context, and some that are really tricky.

-- 
David Kastrup