[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: David Kastrup
Subject: Re: Anybody else with an interest in parser wrangling?
Date: Sun, 19 Mar 2023 19:14:47 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

David Zelinsky <> writes:

> David Kastrup <> 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 <>
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 
    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

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

David Kastrup

reply via email to

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