[Top][All Lists]

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

Re: looking at lilypond data structures

From: Kim Shrier
Subject: Re: looking at lilypond data structures
Date: Sat, 14 Apr 2018 10:26:31 -0600

On Apr 14, 2018, at 2:48 AM, David Kastrup <address@hidden> wrote:
> Kim Shrier <address@hidden> writes:
>> Just to satisfy personal curiosity, I am looking at the lilypond source code
>> so I can get a better feel for what it is up to and how it accomplishes its
>> job.
>> My understanding is that the parser constructs a scheme data structure
>> which is subsequently processed by the iterators to turn it into a stream
>> (or several streams) of musical events.  Before I start looking at the
>> iterators, I would like to see what they are working with for input.
>> So, I have a few questions.
>> Is my understanding correct that the parser produces a single scheme
>> expression that is then processed for use in later stages?
> No.  The parser calls various hook functions for processing elements
> encountered in the input such as scores, markups, books, bookparts.

I got that mistaken impression from reading Erik Sandberg’s paper.
But, I was not seeing it in the source.  Thanks for correcting me.

>> If I wanted to print out this mythical data structure, is there an
>> easy way to do that?
> There is no such data structures.  You might change the respective hook
> functions so that they print material as it is encountered.
>> Is it something that is appropriate to pass to displayMusic or
>> displayScheme?
> Sometimes.
>> How do I get a reference to this data structure?
> There is no such structure.
>> What I would like to do is have lilypond parse some simple files that
>> I would create for the purposes of seeing the different things that
>> the parser generates.
> Basically you need to change the hooks for that kind of thing.  They are
> set up in ly/ such as
> #(define toplevel-book-handler print-book-with-defaults)
> #(define toplevel-bookpart-handler collect-bookpart-for-book)
> #(define toplevel-music-handler collect-music-for-book)
> #(define toplevel-score-handler collect-scores-for-book)
> #(define toplevel-text-handler collect-scores-for-book)
> #(define book-bookpart-handler ly:book-add-bookpart!)
> #(define book-music-handler collect-book-music-for-book)
> #(define book-score-handler ly:book-add-score!)
> #(define book-text-handler ly:book-add-score!)
> #(define bookpart-score-handler ly:book-add-score!)
> #(define bookpart-text-handler ly:book-add-score!)
> #(define bookpart-music-handler collect-book-music-for-book)
> #(define output-def-music-handler context-defs-from-music)
> #(define context-mod-music-handler context-mod-from-music)

Ok.  That matches what I am seeing in lily/parser.yy.  I just wanted
to make sure I hadn’t missed something.

>> If at all possible, I would like to avoid making special hacks in the
>> source for dumping out various data structures.  If I can do what I
>> want from scheme without touching the source, that would be ideal.
> You can just change those hooks as you want to and set them to different
> values.

Thank you again,  You have been very helpful.

> -- 
> David Kastrup


reply via email to

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