make a 2-stage parser

[jwaldmann]

random example from current code: parseClef = (string "\\clef" *> sorc) *> .... This explicitly handles the syntax and semantics (e.g., meaning of arguments) of clef.

I think that's too much for one function, and it would be better to separate these issues:

• surface syntax: literals, commands \foo, blocks { .. }, << .. >>, LISP code (in parens)
• semantics: actual names of commands

So the first part of the parser accepts anything that looks like lilypond on the "surface" (but it does not check names of commands, etc.) producing a tree, and the second part then walks that tree and converts it to something that makes sense (the actual AST that is being used later, e.g., by music-suite)

I think the first part is rather simple (I will try and do it) and the second part can be constructed incrementally (we can ignore subtrees that we don't understand)

We should check what lilypond itself does. Their parser is http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=lily/parser.yy;hb=HEAD and I am not seeing clef, treble etc. there. (Their semantics processing is in Scheme modules, starting from http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=scm/lily.scm;hb=HEAD)

[jwaldmann]

status: c7d4596d4f03a8cb2d86e6fdb016aa796ad57ba8 sort-of-works, can parse 12 of 14 files in ly-examples, remaining errors:

floating point numbers in LISP code

********* aucun-snippet.ly"ly-examples/aucun-snippet.ly" (line 170, column 56):
unexpected "."
expecting letter or digit, ";", space or ")"

slash = { \MakeSlash #20 #1.0 #1.1 #0.05 #0.75 #'(0 . -.5) }
-------------------------------------------------------^

something about angles and braces

********* tab-example.ly"ly-examples/tab-example.ly" (line 26, column 1):
unexpected "}"
expecting item or ">"

  s4. < d'\3 g\2 >8 < gis,\4  d'\3 fis\2 >2\arpeggio ~
  < gis\4 d'\3 fis\2 >2 < b'\2\harmonic e\harmonic >2\fermata
}
^

[jwaldmann]

This plan is now mentioned in the section on Goals for the README.