[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Code for cond*

From: Madhu
Subject: Re: Code for cond*
Date: Thu, 25 Jan 2024 08:46:51 +0530

* JD Smith <1AD5807F-91F7-4B92-BCB0-D0FEA904A75D @gmail.com> :
Wrote on Tue, 23 Jan 2024 23:49:06 -0500:

> In general I’ve always felt cond by itself was missing some
> functionality and could really use the ability to make bindings — a
> cond-let if you will.

[Using an example from another thread]

  (t (let ((temp (cadr whatsis)))
       (cond ((eq temp 'foo))

The idiom i've seen from 80s code is to explicitly pull the bindings to
the outermost scope (like cl loop  does when expanded)

(let (temp)
  (cond ((eq (setq temp (cadr whatsis)) 'foo))

This solves one indentation problem and creates another.

>  Even making and testing bindings local to each
> cond clause would be a real advance[1].  Pattern matching adds another
> level of complexity I hadn’t considered, but overall I'm supportive of
> efforts to improve cond.


> [1] I regularly convince myself that it’s such low hanging fruit, there must 
> in fact already BE a cond-let, and I go hunting for it.  The obvious 
> interface seems like such a straightforward extension of if/when-let, that 
> there would be absolutely nothing new to learn:
> (cond-let
>  (((var value)
>    (dvar (derived-from var))
>    ((has-the-right-stuff-p dvar)))
>   (cons 'correct dvar))
>  (((foo value2)
>    (bar (1- foo))
>    ((< bar 0)))
>   (cons 'incorrect bar))
>  (t nil))

reply via email to

[Prev in Thread] Current Thread [Next in Thread]