bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#59333: [PATCH] Define macro dlet*


From: daanturo
Subject: bug#59333: [PATCH] Define macro dlet*
Date: Sat, 19 Nov 2022 12:29:24 +0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0

On @ 2022-11-17 13:36, Mattias Engdegård wrote:
> The proposed patch also appears incorrect

It was a mistake when I copying and pasting. This patch corrected that and
removed the erroneous breakage mention.


If there would ever be a vote to reduce the number of `let` variants to lighten
the maintenance burden, I bet that the `let*` ones will remain instead of the
versions without the ability to refer to prior bindings. As `let*` can cover
`let` but the reverse is impossible.

```emacs-lisp
(let* ((_a a)
       (a (+ 1 _a))
       (b (+ 2 _a))))
```

Therefore, in my opinion, new `XXXlet` macros variants should be defined like
`XXXlet*` instead, maybe with only `XXXlet*` without `XXXlet`, since we will
eventually need an asterisk version in the future anyway. (Also dash-like easy
destructuring is sweet if possible.)

Why do need to define (publicly) then maintain for eternity `letf`, `flet`,
`dlet`, `lexical-let`, `pcase-let`, `if-let`, `when-let`, etc. when only their
`*` versions should be exposed and encompass every use case just fine?

I think `and-let*` is the most sensible case here as it doesn't have a more
limited `and-let` version.

On 19/11/2022 11:47, Jean Louis wrote:
> * daanturo <daanturo@gmail.com> [2022-11-17 10:16]:
>> --=-=-=
>> Content-Type: text/plain
>>
>> Tags: patch
>>
>>
>> The dlet breakage comes as much surprise to me. There's not even a
>> single entry in NEWS that mentions it.
>>
>>
>> The last line of `dlet' is now:  (let ,binders ,@body))) while I need
>> it to be as below:      (let* ,binders ,@body))
>>
>>
-- 
Daanturo.

Attachment: 0001-Define-macro-dlet-asterisk.patch
Description: Text Data


reply via email to

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