Hi all,

in this mail the thing with defining variables inside of curly brackets popped up the first time in this thread - so I hook here. (If it was mentioned in the former mails it doesn't matter ;-) )


IISC a major change to the codebase would be needed to allow something like this: \bookpart { music = { c''4 } { \music } }
but there are a lot users who would like to use it this way.
I don't want to talk about scopes and coding style, but want to show how I deal with it: Using void-functions is a great thing because the can be called anywhere. So if you want to define something inside a file that is to be included inside curly brackets you can use a function like this:
--------------------------------------
\version "2.19.80"

def = #(define-void-function (sym val)(symbol? scheme?)
         (ly:parser-define! sym val))

\bookpart {
  \def music { c''4 } % this might be part of an included file
  { \music }
}
--------------------------------------
(In lily stable (<2.19) you have to add the parser and location arguments)

Still we have the global scope (OK, I do talk about scope) of the current parser. Now if you want to use some kind of templating mechanism you have two competing needs for the variable names. One approach to create templates is to prepare files to include which use well-named variables. For the piano the file might reference the variables piano_left and piano_right which have to be assigned beforehand. My first scores where for choir. So I was looking for a more flexible templates and I started to write music-functions which store the music in a tree so that my template functions are called "inside" or "on" a base branch. The branches of the tree are the scopes in which the template functions are called. This has the advantage that I can define several pieces of music with several instruments and then can quite easily create a book with several pieces all with there own instrumentation. You can have a look on the result here: https://github.com/jpvoigt/lalily-templates
(I am going to move this OLL-module to the OLL-GitHub-organization)


These are some very rough and quite unstructured thoughts ...
To conclude:
1. defining variables with music- or void-functions is a way to overcome the obstacle of defining variables only on the top-level 2. if the store behind the function allows for hierarchical storage templates (files or functions) can make use of a scope that is not on coding but on a semantic level ... or the like. This should be reworded somehow - I hope you get what I mean.

Jan-Peter



Am 05.03.2018 um 18:24 schrieb Kieren MacMillan:
Hi David,

Q: Included files just behave as if the content was inserted at the same
  position?
Q: Includes must be at top level?

Yes x 2.

Second yes is wrong.

Even if the included file has variable definitions?

Thanks,
Kieren.
________________________________

Kieren MacMillan, composer
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info


_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user



_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Reply via email to