Hello everyone, I am likely in over my head with nesting pairs. I read the documentation link from Jean, and I don't completely understand the internal representation of this nesting in scheme.
dictHymn.HymnOne.ID = "210" dictHymn.HymnOne.Meter = "8.8.8.8" dictHymn.HymnTwo.ID = "344" dictHymn.HymnTwo.Meter = "12.12.12.8" Would it be something like: ( ( HymnOne . (( ID . 210 ) ( Meter . "8.8.8.8" )) ) ( HymnTwo . (( ID . 344 ) ( Meter . "12.12.12.8" )) ) ) assoc-get doesn't seem to work here with the syntactic sugar, likely because I may not understand how nested pairs work. dictHymnValue = #(ly:assoc-get 'ID dictHymn.HymnOne "error") \markup \dictHymnValue Many thanks, mattfong On Sun, Oct 18, 2020 at 3:35 PM David Kastrup <[email protected]> wrote: > Jean Abou Samra <[email protected]> writes: > > > Le 18/10/2020 à 22:10, Matthew Fong a écrit : > > > >> Hello Aaron and Jean, > >> > >> Many thanks for pointing out the finer points of syntax of Scheme > >> vs. LilyPond. > >> > >> I appreciate the Scheme quoting reference, and the syntactic > >> sugar. Still so much more to learn here! > > > > You live and learn; I learnt about the synctactic sugar just today. > > Lots of syntactic sugar came into being in the last few versions. This > particular bit has been around a while. > > commit 59d1c295b6c6ebe9410362cc365349bd458b0bcf > Author: Joe Neeman <[email protected]> > Date: Tue Dec 22 21:44:56 2009 -0800 > > Add nested properties setting to \paper blocks. > > Though this would have needed writing > > var #'prop #'prep = ... > > instead of > > var.prop.prep = ... > > at that time. The availability of the latter syntax was probably an > unintended side effect of > > commit 864ce06c432a62191773b0d59401348c9b51568c > Author: David Kastrup <[email protected]> > Date: Mon Oct 8 17:52:36 2012 +0200 > > Allow property and grob paths to be constructed from strings > > This allows use of either > \override Accidental color = #red > or > \override Accidental.color = #red > (in addition to existing forms), both for context modifications or for > property overrides in music, the latter with optional leading context > spec defaulting to Bottom. . The same holds for reverts. > > which would peg this as 2.17.6 (quite later than I would have thought). > I think that this assignment-level syntax only got formalised later on. > > -- > David Kastrup >
