Re: Doc: Extending - rewrite - LilyPond Variables (issue 309820043 by address@hidden)

[pkx166h]

Thanks David.


https://codereview.appspot.com/309820043/diff/1/Documentation/extending/scheme-tutorial.itely
File Documentation/extending/scheme-tutorial.itely (right):

https://codereview.appspot.com/309820043/diff/1/Documentation/extending/scheme-tutorial.itely#newcode785
Documentation/extending/scheme-tutorial.itely:785: the variable's value.
 For that reason, music functions in LilyPond do
On 2016/07/31 17:09:56, dak wrote:
> I'm pretty sure that I wrote this originally.  "Since" and "for that
reason" is
> both pretty misleading since the creation of a copy is not a _reason_
but an
> _excuse_ for being allowed to modify arguments.

> It's more like:
> ---
> Scheme allows modifying complex expressions in-place, and LilyPond
makes
> extensive use of this when transforming music with music functions.
But when
> music expressions are stored in variables rather than entered
directly, the
> usual expectation when passing them to music functions would be to
keep the
> original value unmodified.  So when referencing a music variable with
leading
> backslash as @code{\twentyFour}, LilyPond creates a copy of that
variable's
> music value for use in the surrounding music expression rather than
using the
> variable's value directly.

> Therefore, Scheme music expressions written with...
> ---
> Something like that, reworded until the reworder thinks it makes
sense.

Done.

https://codereview.appspot.com/309820043/