> On Jan 25, 2024, at 10:44 AM, Alfred M. Szmidt wrote: > > > > >> On Jan 25, 2024, at 10:17 AM, JD Smith wrote: >> >> >> >>> On Jan 25, 2024, at 8:57 AM, Stefan Monnier wrote: >>> >>>>> >>>>> (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)) >>> >> >>> Personally, I was thinking of a syntax like >>> >>> (my-cond >>> (:let var value) >>> (:let dvar (derived-from var)) >>> ((has-the-right-stuff-p dvar) >>> (cons 'correct dvar)) >>> >>> (:let foo value2) >>> (:let bar (1- foo)) >>> ((< bar 0) >>> (cons 'incorrect bar)) >>> >>> (t nil)) > > And it perhaps goes without saying that the two approaches could be combined :) — > > (cond-let > (:let var-for-rest value) > > Is there a reason why using a keyword here? How would multiple > bindings be handled -- or is that what the two forms: > > (:let foo value2) > (:let bar (1- foo)) > > try to convey? Stefan correct me if I’m missing the main point, but I think the difference motivating a special form like (:let …) comes from the desire to establish bindings for all the rest of the clauses, and to make it clear you are doing this. I don’t know the right way to handle that (or how important it is). The proposed cond* has that capability. My cond-let idea has somewhat different goals, akin to a short-circuiting group of when + when-let’s. Its clause syntax is just a straightforward copy of when-let; hence no new syntax to learn.