Documentation/inputformat

   1 General format of a construct:
   2
   3         BLOCKNAME {  <info to go with this block>   }
   4
   5 Some types allow declarations:
   6
   7         IDENTIFIER = BLOCKNAME {
   8                 <info to go with this block>
   9         }
  10
  11         ..
  12
  13         BLOCKNAME {
  14                 IDENTIFIER
  15                 ...
  16         }
  17
  18
  19 In musicmode, eg,
  20
  21         ''!c8.-"text"_v
  22
  23 a lot of characters parse differently
  24 than in "command" mode, eg,
  25
  26         identifier = score { .. }
  27
  28 So you have to signal that to the tokenizer. This is done with
  29 '$'. '$' is a delimiter, which used by the tokenizer only.
  30
  31 * musicmode: The brace still is used to group grammatical groups.
  32 * musicmode: "word" are preceded by a '\' (backslash)
  33
  34 This means you can write some stuff in a zillion ways:
  35
  36 1.      $\var = \blockname { ... } $
  37
  38 2.      var = blockname { $ ... $ }
  39
  40 3.      var = $ $ $\blockname {  ... $ }
  41
  42 COMMENTS
  43
  44 not really crystallized; you can use '#' or '%' as line comment
  45
  46 OTHER
  47
  48 A correctly parsed .ly does not guarantuee output. A lot (most) of the
  49 checking is done *after* parsing (some checks even are done after the
  50 break calc!);  I'm sorry.
  51
  52 The parser's job is to construct appropriate objects. It will *only*
  53 detect parse errors.
  54
  55 LilyPond first reads 'symbol.ini', which contains declarations crucial
  56 to proper operation of LilyPond (symbol tables, note names)
  57
  58 This language looks a lot like Rayce's which in turn owes a lot to the
  59 POVRay raytracer. Now, I know, musictypesetting and Raytracing do not
  60 necessarily require the same input format, but I was just to lazy to
  61 make up a new/better input format. Suggestions welcome.