Modifying nested dictionary/alist type data

Modifying nested dictionary/alist type data

[Paul Morris]

Hi, I’m rewriting one of LilyPond's C++ routines in Guile/Scheme in order to customize it for my own use, and it uses some nested dictionary/map/alist-style data structures that you can modify using something like this in C++:

  mydata[aaa][bbb].ccc = 10;

Ok, maybe use alists, but how to modify the nested values? ...given that you need an extra “set!” operation to do this reliably, as shown in the documentation:

(set! address-list
      (assoc-set! address-list "bob" "11 Newington Avenue"))

But if you have nested alists like this

  (define my-alist ‘((aaa . ((bbb . ((ccc . 10)))))))

and you want to change ccc, then the “set!” trick doesn’t help. (...what would you “set!”?)  So what’s the best approach here for such nested data structures?  Maybe I should just use nested hash maps instead?  Sorry if I’m missing something obvious.

Thanks,
-Paul

Re: Modifying nested dictionary/alist type data

[Wette, Matthew R (3441)]

> On Apr 14, 2016, at 4:44 PM, Paul Morris <paul@paulwmorris.com> wrote:

> But if you have nested alists like this
> 
>  (define my-alist ‘((aaa . ((bbb . ((ccc . 10)))))))
> 
> and you want to change ccc, then the “set!” trick doesn’t help. (...what would you “set!”?)  So what’s the best approach here for such nested data structures?  Maybe I should just use nested hash maps instead?  Sorry if I’m missing something obvious.

Not sure I understand this entirely, but have you looked at boxes?  Look at SRFI-111 in the Guile Reference.  

Re: Modifying nested dictionary/alist type data

[Andreas Rottmann]

Paul Morris <paul@paulwmorris.com> writes:

> Hi, I’m rewriting one of LilyPond's C++ routines in Guile/Scheme in
> order to customize it for my own use, and it uses some nested
> dictionary/map/alist-style data structures that you can modify using
> something like this in C++:
>
>   mydata[aaa][bbb].ccc = 10;
>
Depending on the number of entries in each nesting level, and other
(performance/space) tradeoffs, hash tables might be a good fit as an
associative array data structure:

https://www.gnu.org/software/guile/manual/html_node/Hash-Tables.html
http://srfi.schemers.org/srfi-69/srfi-69.html
http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-14.html

Guile 2.0 supports all three of these APIs -- choosing between them is
mostly important if you care about portability to different Scheme
implementations (which I'd guess is not high priority in the context of
lilypond).

HTH, Rotty
-- 
Andreas Rottmann -- <http://rotty.xx.vu/>

Re: Modifying nested dictionary/alist type data

[Paul Morris]

> On Apr 15, 2016, at 1:20 PM, Andreas Rottmann <a.rottmann@gmx.at> wrote:
> 
> Depending on the number of entries in each nesting level, and other
> (performance/space) tradeoffs, hash tables might be a good fit as an
> associative array data structure:
> 
> https://www.gnu.org/software/guile/manual/html_node/Hash-Tables.html
> http://srfi.schemers.org/srfi-69/srfi-69.html
> http://www.r6rs.org/final/html/r6rs-lib/r6rs-lib-Z-H-14.html
> 
> Guile 2.0 supports all three of these APIs -- choosing between them is
> mostly important if you care about portability to different Scheme
> implementations (which I'd guess is not high priority in the context of
> lilypond).

Thanks for your help.  It looks like a hash table containing nested vectors should work well for this case.  I think I’ll just stick with the syntax from the Guile manual.  I don’t suppose there's any general guidance on how big a given hash table should be for it to make sense to use a hash table, in terms of performance/space tradeoffs?

Also good to know about the boxes from SRFI-111.  They might come in handy, especially when rewriting C++ code in Scheme.

-Paul