Re: variables in \book { }

[David Kastrup]

Graham King <address@hidden> writes:

> On Wed, 2016-02-17 at 10:58 +0100, David Kastrup wrote:
>
>> The problem with the repeated use of "I've tried that" is that nobody
>> can really guess just _what_ exactly you have tried with what error
>> messages as the result.  And nobody can try reproducing or debugging or
>> diagnosing the problem since there is no code to work with.
>> 
>
> David,
> my apologies.  You've underestimated my ignorance: I didn't realise that
> "The \book block does not really have a scope of its own..." implied
> that there is no solution.  I'm sorry to have cost you your time and
> frustration.
>
> For what it's worth, here is how I now understand my error:
>
>           music = \relative { c' d e f }
>           \score {
>             \music
>           }
>
> works just fine.  When the Learning Manual (at section 3.1.1) says: "If
> you haven't explicitly added [a \book block], LilyPond wraps your entire
> input code in a \book block implicitly." it does _not_ mean that the
> above code is equivalent to:
>
>           \book {
>             music = \relative { c' d e f }
>             \score {
>              \music
>             }
>           }

The problem is that it would likely be possible to teach LilyPond's
parser to accept the latter, but due to book not having a scope of its
own for music expressions, it would be perfectly equivalent to the
first: any such assignment would change "music" globally.  Also it would
take effect immediately whereas changes in the paper block (or header)
take effect when the book ends and its score expressions are actually
iterated.

> but rather:
>
>           music = \relative { c' d e f }
>           \book {
>             \score {
>               \music
>             }
>           }

Well, the "equivalence" is not really meant syntactically but
semantically.  So the "if this was legal syntax, it would mean that" is
implied.  It might be that the wording in the Learning Manual is a bit
of an oversimplification.

> So, for my immediate problem, I'll bite the bullet and create a
> namespace in which I can define all 12 instances of the various
> variables involved, and put the definitions outside the \book { ... }.

With the same caveat about global scoping and life time of variables,
one can use #(define ...) instead of assignments.  The cleaner solution
really is "biting the bullet" here.

-- 
David Kastrup