Re: Code for cond*

[João Távora]

On Wed, Jan 24, 2024 at 1:30 PM Ihor Radchenko <yantar92@posteo.net> wrote:
>
> Po Lu <luangruo@yahoo.com> writes:
>
> >>>   (let (x y z)
> >>>     (cond ((eq (setq x ...) 'bar)
> >>>            yyy)
> >>>           ((setq y (... x))
> >>>            zzz)
> >>>           ...and so on
> >>>
> >>> This alone is too important a feature to be consigned to ELPA.
> >>
> >> May you elaborate how cond* helps simplifying the above example?
> >
> > It will be possible for a clause to bind variables accessible in
> > subsequent ones, eliminating the let and setq forms.
>
> The problem is that cond* is doing much more than just introducing
> fall-through bindings.
>
> If we just need fall-through bindings, I'd argue that we should better
> introduce them separately; maybe even as a part of the normal `cond'.

Aren't fallthrough bindings just a code smell, anyway? I mean, I've
used that 'setq' pattern in the past, but my intention is _never_
to get fallthrough, but to delay a potentially expensive
calculation to  just the point where it becomes useful for a
single clause.

I could easily use pcase for that, and the bindings would
be local to that clause.  If I need more clauses, I should
do a sub-cond, or sub-pcase.  That is the way IMHO.

Code-smell or not, it is nevertheless bizarre or at least
unhealthy -- multiple people have pointed that out --
that the new cond* fall-through bindings don't lexically wrap
their users.

João