Re: scheme-question about accumulating lists of lists

[Thomas Morley]

Am So., 21. Apr. 2019 um 23:51 Uhr schrieb David Pirotte <address@hidden>:

> > Whether 'pattern matching' will be useful to hide complexity to make
> > life easier for our users or whether it adds an abstraction layer,
> > which would make it even harder for users to write their own
> > guile-code, I can't judge currently.
>
> Ok, I believe it does help a lot, maybe even more scheme beginners actually, 
> and so
> do our maintainers, here is an extract of the (latest) manual, section "6.6.8 
> Pairs":
>
>         ...
>         Since a very common operation in Scheme programs is to access the car 
> of a
>         car of a pair, or the car of the cdr of a pair, etc., the procedures 
> called
>         caar, cadr and so on are also predefined. However, using these 
> procedures is
>         often detrimental to readability, and error-prone. Thus, accessing the
>         contents of a list is usually better achieved using pattern matching
>         techniques (see Pattern Matching).
>         ...
>
> But of course do as you wish, there is nothing 'wrong' writing good scheme 
> code using
> 'old' destructuring techniques, but it will, always imo, be more difficult to 
> read
> and maintain.

Hi David,

please don't get me wrong, read my "I can't judge currently" as: I
don't have the knowledge yet to say anything reasonable about (ice-9
match).

To increase my knowledge I started playing around with `match´ and
tried to get all LP-grob-names which are Spanner out of
`all-grob-descriptions`.
`all-grob-descriptions` is an alist, if you don't have LilyPond at
hand you may use `test-alist` below.

In the example below (all in a .ly-file, but apart from
`lp-assoc-get-condition´ it works in a guile-prompt as well) I coded
different conditions how to get the result.
`lp-assoc-get-condition´ is what I'd use
`alist-searching-condition´ is also possible ofcourse, don't using own
LP-procedures.
`core-guile-condition´ has the worst syntax I could think of ;)

#(begin

(define test-alist
  '(
    (Name-1
     . (
        (foo . x)
        (bar . y)
        (buzz . z)
        (meta . ((name . Name-1)
                 (class . Spanner)
                 (ifaces . (i1 i2 i3)))))))
    ;; (Name2 . ...) etc
                 )

(define (core-guile-condition g) ;; worst
  (and
    (eq? 'Spanner (cdr (car (cdr (cdr (car (last-pair (cdr g))))))))
    (car g)))

(define (alist-searching-condition g)
  (and (eq? 'Spanner (assq-ref (assq-ref (cdr g) 'meta) 'class)) (car g)))

(define (lp-assoc-get-condition g)
  ;;`assoc-get´ relies on C++ defined `ly:assoc-get´
  ;; From LP Internal Reference:
  ;; Function: ly:assoc-get key alist default-value strict-checking
  ;;   Return value if key in alist, else default-value (or #f if not
specified).
  ;;   If strict-checking is set to #t and key is not in alist, a
  ;;   programming_error is output.
  (and (eq? 'Spanner (assoc-get 'class (assoc-get 'meta (cdr g)))) (car g)))

(pretty-print
  (filter-map
    core-guile-condition
    ;alist-searching-condition
    ;lp-assoc-get-condition
  ;all-grob-descriptions
  test-alist
  ))
  )

Now `core-guile-condition´ feels like a case for `match´, but I
couldn't make it work.
Is this a bad use case and alist searching is always preferable?

As a side note.
I'd like to download the "Guile Reference Manual" as one big-page
.html, but couldn't find any for 2.9.1.
Not yet done?

Thanks,
  Harm