Re: [GSoC] Proposal: Modular LilyPond Parser (C++)

I tried this:

#(define-music-function (clef name) (string?)
    #{
      \original-clef #name
      c'1 d'
    #})

\score {
   \new Staff {
     \clef "treble"
     g'1
   }
}

I can't tell you how many times I've mixed up \key and \clef. Luckily, 
clef = \time... doesn't work for me; otherwise, as a 'German child', I 
might be tempted to change it and end up confusing you all completely. ;o)

I have the same confusion with \time and \times. I forgot to mention 
that my trie always uses the 'longest match' to split \times2/3 into 
\times and 2/3.

This works:

clef = { \repeat infold 12 c'4 } \score { \new Staff { \clef } }

Thanks for the info that quite a bit has changed since version 2.14. I 
might take a look at the older versions.

Overall, I think we agree:
- having more possibilities in Scheme definitely has its advantages.
- Ideally, YAML would be ingested, mapped into trie structures, and 
linked with the lexer mode so that ambiguities can be resolved early and 
deterministically. This would make my parser easily extensible.
- I don't want unpredictable automatic ambiguity resolution (no GLR 
parsing). Everything should be manageable and easy to maintain. The key 
is that all ambiguities must be resolvable via context.

In the end, it would be helpful if we could go through how my AST nodes 
in C++ correspond to the internal music objects in Scheme. My 
understanding is that the basic structures (e.g., SequentialMusic, 
SimultaneousMusic, NoteEvent, etc.) are largely congruent.

Christian