Maybe I ought to avoid such complexity. I constructed an example in guile,
and it's unclear how I access data for n hymns arranged this way. Scheme is
definitely not like Python.
guile> ( define b '((1 . '((11 . "aa") (22 . "bb") (33 . "cc")))
(2 . '((44 . "dd") (55 . "ee") (66 . "ff")))
(3 . '((77 . "gg") (88 . "hh") (99 . "ii")))
)
)
guile> b
((1 quote ((11 . "aa") (22 . "bb") (33 . "cc"))) (2 quote ((44 . "dd") (55
. "ee") (66 . "ff"))) (3 quote ((77 . "gg") (88 . "hh") (99 . "ii"))))
guile> (list? b)
#t
guile> (list b)
(((1 quote ((11 . "aa") (22 . "bb") (33 . "cc"))) (2 quote ((44 . "dd") (55
. "ee") (66 . "ff"))) (3 quote ((77 . "gg") (88 . "hh") (99 . "ii")))))
guile> (car b)
(1 quote ((11 . "aa") (22 . "bb") (33 . "cc")))
guile> (cdr b)
((2 quote ((44 . "dd") (55 . "ee") (66 . "ff"))) (3 quote ((77 . "gg") (88
. "hh") (99 . "ii"))))
guile> (car (car b))
1
guile> (car (cdr b))
(2 quote ((44 . "dd") (55 . "ee") (66 . "ff")))
guile>
Many thanks,
mattfong
On Sun, Oct 18, 2020 at 5:36 PM Matthew Fong <oxen...@gmail.com> wrote:
> 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 <d...@gnu.org> wrote:
>
>> Jean Abou Samra <j...@abou-samra.fr> 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 <joenee...@gmail.com>
>> 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 <d...@gnu.org>
>> 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
>>
>
