Re: Scheme: Syntax for storing a variable in an alist

[Matthew Fong]

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 <oxengen@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 <dak@gnu.org> wrote:

Jean Abou Samra <jean@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 <joeneeman@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 <dak@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