Am Do., 17. Nov. 2022 um 03:12 Uhr schrieb Jeremy Steward
<xxxxxx@thatgeoguy.ca>:
>
> > (let-values (((d) (using c
> >                              (k c)))
> >                     ((a) (f))
> >                     ((c) (using b
> >                              (h b)))
> >                     ((b) (g)))
> >    <expr>)
>
> The example here - from an ergonomics perspective the extra parens
> around (d) / (a) / (c) / (b) seem unwarranted.

This is just because I used the let-values and not the let variant.
The former is more general.  The let variant would be

(let ((d (using c
             (k c)))
        (a (f))
        (c (using b
              (h b)))
        (b (g)))
  <expr>)

> Likewise, I'm recalling that a lot of the binding here is really a
> matter of matching the ordering based on dependencies. Another thread
> commented on how this is similar to Makefile syntax and I'd agree that
> there's some pattern matching going on here.

The relationship to Makefile syntax is that a topological sort is
happening in the background.

> Which makes me think there's a match-let in here somewhere that's
> itching to come out. Thinking similar to
> <https://api.call-cc.org/5/doc/matchable/match-let>, although not quite
> how it is exposed there since the Wright-Cartwright-Shinn matcher seems
> to propagate some of the unfortunate baggage of |let|.
>
> I understand that SRFI 241 doesn't contain this, but when binding
> multiple arguments at once I always feel like the matching syntax seems
> to better express the idea.
>
> Thoughts? Is |let| a distraction from a more ergonomic form?

match-let does not bind multiple values but matches against, say, a
list.  This is different from the above.