lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Doc: Extending - rewrite - LilyPond Variables (issue 309820043 by addres


From: dak
Subject: Doc: Extending - rewrite - LilyPond Variables (issue 309820043 by address@hidden)
Date: Sun, 31 Jul 2016 10:09:56 -0700


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
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.

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]