#@{ @var{Lilypond code} #@}
@end example
They can be used anywhere where you can write Scheme code: the Scheme
-reader actually is changed for accommodating Lilypond code blocks. When
-the Lilypond code block is being read, it is parsed superficially and
-replaced by a call to the Lilypond @code{parser} which is executed at
-runtime to interpret the Lilypond code block.
+reader actually is changed for accommodating LilyPond code blocks. When
+the LilyPond code block is being read, it is parsed superficially and
+replaced by a call to the LilyPond @code{parser} which is executed at
+runtime to interpret the LilyPond code block.
The point of the superficial parsing is the interpretation of @code{$}
signs which can be used for splicing in expressions from the surrounding
@table @code
@item $$
-just passes a single @code{$} to the Lilypond parser.
+just passes a single @code{$} to the LilyPond parser.
@item $@var{form}
will evaluate the Scheme form at runtime and splice its value as an
-identifier @code{\form} into the Lilypond parser. Depending on the
+identifier @code{\form} into the LilyPond parser. Depending on the
value type, it may be interpreted as several different syntactic
entities.
@item #$@var{form}
will evaluate the Scheme form at runtime and splice its value as a
-Scheme expression into the Lilypond parser.
+Scheme expression into the LilyPond parser.
@item #@var{form}
Forms in Scheme expressions started with @code{#} are read and parsed
recursively for @code{$} signs. Those are treated as follows:
splices the value of the variable into the surrounding expression.
@item #@dots{}($ @var{form} @dots{})
splices the value of the form into the surrounding expression. As
-opposed to a Lilypond level @code{$@var{form}}, you need to separate the
+opposed to a LilyPond level @code{$@var{form}}, you need to separate the
form with a blank, making @code{$} be recognizable as a separate Scheme
symbol.
@end table
@node Scheme functions
@section Scheme functions
-@cindex Scheme functions (Lilypond syntax)
+@cindex Scheme functions (LilyPond syntax)
@emph{Scheme functions} are Scheme procedures that can create Scheme
-expressions from input written in Lilypond syntax. They can be called
+expressions from input written in LilyPond syntax. They can be called
in pretty much all places where using @code{#} for specifying a value in
Scheme syntax is allowed. While Scheme has functions of its own, this
chapter is concerned with @emph{syntactic} functions, functions that
-receive arguments specified in Lilypond syntax.
+receive arguments specified in LilyPond syntax.
@menu
* Scheme function definitions::
@multitable @columnfractions .33 .66
@item @code{parser}
-@tab needs to be literally @code{parser} in order to give Lilypond code
+@tab needs to be literally @code{parser} in order to give LilyPond code
blocks (@code{#@{}@dots{}@code{#@}}) access to the parser.
@item @code{@var{argN}}
@code{(@emph{predicate?} @emph{default})} for specifying optional
arguments. If the actual argument is missing when the function is being
called, the default value is substituted instead. Default values are
-evaluated at definition time (including Lilypond code blocks!), so if
+evaluated at definition time (including LilyPond code blocks!), so if
you need a default calculated at runtime, instead write a special value
you can easily recognize. If you write the predicate in parentheses but
don't follow it with a default value, @code{#f} is used as the default.
@noindent
Some type predicates are specially recognized by the parser and will
-make the parser look for the respective arguments in Lilypond syntax
+make the parser look for the respective arguments in LilyPond syntax
rather than in Scheme syntax. Currently these are @code{ly:music?},
@code{markup?}, @code{ly:pitch?}, and @code{ly:duration?}.
If you really want to input one of the special items as a Scheme rather
-than a Lilypond expression, you may write them as a Scheme expression
+than a LilyPond expression, you may write them as a Scheme expression
that calls @code{ly:export} at its outermost level.
Other type predicates, including user-defined ones, will make the
part of the music argument or not.
In those rare cases, you have to delimit your music arguments
-appropriately to spare Lilypond from getting confused.
+appropriately to spare LilyPond from getting confused.
@node Void scheme functions
@subsection Void scheme functions
@noindent
This example demonstrates the main translation rules between regular
LilyPond markup syntax and Scheme markup syntax. Using @code{#@{
-@dots{} #@}} for entering in Lilypond syntax will often be most
+@dots{} #@}} for entering in LilyPond syntax will often be most
convenient, but we explain how to use the @code{markup} macro to get a
Scheme-only solution.