Email list hosting service & mailing list manager

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)
Re: [RFC] alist-let: let-like alist destructuring syntax siiky (14 Aug 2022 11:23 UTC)

Re: [RFC] alist-let: let-like alist destructuring syntax siiky 14 Aug 2022 11:23 UTC

Think I got an OK implementation. You can read it here[0]. I also
changed the syntax slightly in the process:

(alist-values =? ALIST LVAR ...)

LVAR ::= KEY
        | (KEY)
        | (KEY DEFAULT)

(alist-let =? ALIST (LVAR ...)
   BODY ...)

LVAR ::= (VAR KEY)
        | (VAR KEY DEFAULT)

=? is the key equality test. In retrospect I don't think it makes sense
to have an optional key equality test for each key, because it has to be
"compatible" with all keys of the alist. Instead, the equality test is
now mandatory and will be used for all key-based lookups.

For some dictionary types other than alists requiring the equality test
may not make sense (e.g. SRFI 69 hash tables). So the *-let syntax may
be slightly different, but very little change to switch dictionary types
will be required.

Waiting for comments on what people think. Next (don't know when) I'll
try to use Zipheir's idea of a "binder-maker"[1].

[0]: https://git.sr.ht/~siiky/alist-let/tree/main/item/alist-let.scm
[1]: http://ix.io/3Zfd