Hi Marc and siiky,

First of all, I think this might be form, but that it would be much
more convenient if it could be parameterized on any dictionary type.
This could be done through SRFI 225, or through a simple builder macro,
e.g. something of the form

(make-dict-binder binding-name dict-type-pred assoc-form),

which would allow alist-let to be defined by

(make-dict-binder alist-let list? alist-ref)

On 2022-06-03 17:08 +0200, Marc Nieper-Wißkirchen wrote:
> Am Fr., 3. Juni 2022 um 15:10 Uhr schrieb siiky <xxxxxx@net-c.cat>:
> >
> > (let ((foo (alist-ref 'foo al))
> >        (bar (alist-ref 'bar al))
> >        (x (alist-ref 'zaz al))
> >        BINDING ...)
> >    ; Do something with foo, bar, x, ...
> >    BODY ...)
> >
>
> This, and any macro expanding in such a piece of code is not very
> efficient, i.e. O(n²) instead of the optimal O(n).

True, but, since we're talking about O(n)-lookup alists, who
cares about *this* inefficiency?  Anyone using alists either
(a) has ensured they're really short, or (b) doesn't care if
they're slow, because they're writing a prototype or something
quick and dirty.

In any case, this is an alist-specific inefficiency.  Other forms
with asymptotically faster 'ref' procedures wouldn't have this
issue, were alist-let generalized as I've suggested.

> That said, a general problem with an alist-let macro like the one you
> propose is that it confuses identifiers and symbols.  The keys of your
> alist are symbols while the variables are represented by identifiers that,
> for example, can be renamed ones through invocations of hygienic macros.

Agreed, this is the funkiest thing about this form.  I tend to
prefer the simple solution of requiring an identifier, but your
':' idea is also quite interesting.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>