[RFC] alist-let: let-like alist destructuring syntax siiky (03 Jun 2022 13:10 UTC)
Re: [RFC] alist-let: let-like alist destructuring syntax Marc Nieper-Wißkirchen (03 Jun 2022 15:08 UTC)
Re: [RFC] alist-let: let-like alist destructuring syntax Marc Nieper-Wißkirchen (03 Jun 2022 15:33 UTC)
Re: [RFC] alist-let: let-like alist destructuring syntax Wolfgang Corcoran-Mathe (03 Jun 2022 18:53 UTC)
Re: [RFC] alist-let: let-like alist destructuring syntax Marc Nieper-Wißkirchen (03 Jun 2022 19:08 UTC)
Re: [RFC] alist-let: let-like alist destructuring syntax Marc Nieper-Wißkirchen (30 Jun 2022 16:40 UTC)

[RFC] alist-let: let-like alist destructuring syntax siiky 03 Jun 2022 13:10 UTC

Hey all,

I don't know of any convenient way to work with alist values, --
destructuring (by key) and binding values to variables -- that doesn't
involve manually

(let ((foo (alist-ref 'foo al))
       (bar (alist-ref 'bar al))
       (x (alist-ref 'zaz al))
       BINDING ...)
   ; Do something with foo, bar, x, ...
   BODY ...)

(`alist-ref`[0] is CHICKEN specific; probably does what you expect)

I've wondered why that is since alists are kind of the "default"
key/value map representation -- the easiest to get going with, at least.

Because of that I came up with an `alist-let` macro when I had the need,
and now would like to RFC on the idea.

  1. Is there some similar construct that I've missed? I searched,
though not very exhaustively, the SRFI archives and the CHICKEN docs but
nothing (seemingly relevant) came up.
  2. If there isn't some such construct, why? Some detail that makes it
infeasible or not too useful in the general case?
  3. Is anyone else interested in such a macro?
  4. If yes, is anyone else interested in working on such a macro (with me)?

I had a chat on #scheme with Zipheir about this. RE (1), they suggested
pattern matching, but AFAIK you can't destructure alists by key with
`matchable`[1] (the only pattern matching library I'm familiar with).
Are there other pattern matchers capable of destructuring by key?

They also gave the idea of implementing this syntax not only for alists
but for any dictionary-like structure (with SRFI 225). I think this is a
great idea! But, personally, I would like to get a well ironed out
syntax first, that is the most useful/most general/easiest to use. I
just think it would be better to get some use out of the syntax first
and see how it fares (with alists or any other specific structure),
before trying to fry that particular fish.

-----

You can find the code of my latest iteration of `alist-let` (plus the
`/and` and `/nor` variants) here[2], the docs here[3], and an example
also on the docs here[4]. I'm still not completely satisfied with the
current syntax, but boy is it handy!

The status right now (limitation/supported features):

  + You can bind values of an alist, by key, with a `let`-like syntax;
  + The name of the variable is the key itself, by default, but you may
optionally use a different name;
  - Keys must be symbols;
  - There's no way to specify the default value returned for a binding
when the key doesn't exist in the alist.

So that you don't have to follow too many links to hunt for examples,
with `alist-let` you can write this to mean the same as the `let` at the
top of the email:

(alist-let al (foo bar (x zaz) BINDING ...)
   ; Do something with foo, bar, x, ...
   BODY ...)

Many different variations with slightly different semantics are
possible, but let's start with the basics. :)

-----

Turned out a bit dense, but WDYT?

[0]: https://api.call-cc.org/5/doc/chicken/base/alist-ref
[1]: https://wiki.call-cc.org/eggref/5/matchable
[2]:
https://github.com/siiky/transmission.scm/blob/f0668c1421ce3a0955dcacbaf88c3b510f2fc486/transmission.utils.scm#L86-L111
[3]: https://api.call-cc.org/5/doc/transmission/alist-let
[4]: https://wiki.call-cc.org/eggref/5/transmission#example

siiky