GNU bug report logs - #59333
[PATCH] Define macro dlet*

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59333 in the body.
You can then email your comments to 59333 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: daanturo <daanturo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Define macro dlet*
Date: Thu, 17 Nov 2022 14:13:35 +0700

[Message part 1 (text/plain, inline)]

--=-=-=
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.

I would rather prefer b72f88518b89560accf740a4548368863e6238e0 be
reverted, though. But maybe that's fine if the majority of maintainers
agree with that change. But please mention similar breakages more
universally.



In GNU Emacs 29.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.34, cairo version 1.17.6) of 2022-11-13 built on dan-laptop
Repository revision: b806e8a8a2c7d01a18f11e6582961c42a9eecc01
Repository branch: makepkg
System Description: Arch Linux

Configured using:
'configure --sysconfdir=/etc --prefix=/usr --libexecdir=/usr/lib
--localstatedir=/var
'--program-transform-name=s/\([ec]tags\)/\1.emacs/' --with-json
--with-libsystemd --with-mailutils --with-modules --with-pgtk
--without-xaw3d --with-sound=alsa --with-xinput2 --with-xwidgets
--without-compress-install --with-native-compilation=aot
--with-tree-sitter 'CFLAGS=-march=native -O2 -pipe -fno-plt
-fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection'
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

--=-=-=--

-- 
Daanturo.

[0001-Define-macro-dlet-star.patch (text/x-patch, attachment)]

Message #8 received at 59333 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: daanturo <daanturo <at> gmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Mattias Engdegård <mattiase <at> acm.org>
Cc: 59333 <at> debbugs.gnu.org
Subject: Re: bug#59333: [PATCH] Define macro dlet*
Date: Thu, 17 Nov 2022 09:25:00 +0200

> Date: Thu, 17 Nov 2022 14:13:35 +0700
> From: daanturo <daanturo <at> gmail.com>
> 
> The dlet breakage comes as much surprise to me. There's not even a
> single entry in NEWS that mentions it.

dlet was new in Emacs 28, and the change you mention was done before
Emacs 28 was released.  So NEWS just mentions the introduction of
dlet, and that is enough.

> I would rather prefer b72f88518b89560accf740a4548368863e6238e0 be
> reverted, though. But maybe that's fine if the majority of maintainers
> agree with that change. But please mention similar breakages more
> universally.

I can only understand the breakage if someone picked up dlet as
originally implemented on master, before Emacs 28 was released.  In
that case, it's the risk people take when they follow the development
code too closely.

As for the patch, I'd like to hear opinions about the need for dlet*.

Thanks.

Message #11 received at 59333 <at> debbugs.gnu.org (full text, mbox):

From: Daan Ro <daanturo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 59333 <at> debbugs.gnu.org
Subject: Re: bug#59333: [PATCH] Define macro dlet*
Date: Thu, 17 Nov 2022 14:40:16 +0700

[Message part 1 (text/plain, inline)]

> dlet was new in Emacs 28, and the change you mention was done before
> Emacs 28 was released.  So NEWS just mentions the introduction of
> dlet, and that is enough.

Sorry it was my fault for not paying attention to the commit year (I thought
that was August this year).

Therefore reverting it now must not be an option.

But I think let* is more useful than let in general for programming, as it
let
us create successive bindings and transform the flow of data, like the
natural
flow of thought.

[Message part 2 (text/html, inline)]

Message #14 received at 59333 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 59333 <at> debbugs.gnu.org, daanturo <daanturo <at> gmail.com>
Subject: Re: bug#59333: [PATCH] Define macro dlet*
Date: Thu, 17 Nov 2022 08:22:24 -0500

> As for the patch, I'd like to hear opinions about the need for dlet*.

Currently I see very few uses of `dlet`, so adding `dlet*`
seems overkill.


        Stefan

Message #17 received at 59333 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 59333 <at> debbugs.gnu.org,
 daanturo <daanturo <at> gmail.com>
Subject: Re: bug#59333: [PATCH] Define macro dlet*
Date: Thu, 17 Nov 2022 14:36:39 +0100

17 nov. 2022 kl. 14.22 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

> Currently I see very few uses of `dlet`, so adding `dlet*`
> seems overkill.

I concur. (The proposed patch also appears incorrect, and lacks a test.)
Anyone really needing a `dlet*` macro can easily implement one in terms of `dlet`.

Message #20 received at 59333 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 59333 <at> debbugs.gnu.org, daanturo <daanturo <at> gmail.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#59333: [PATCH] Define macro dlet*
Date: Sat, 19 Nov 2022 07:28:18 +0300

* Eli Zaretskii <eliz <at> gnu.org> [2022-11-17 10:27]:
> I can only understand the breakage if someone picked up dlet as
> originally implemented on master, before Emacs 28 was released.  In
> that case, it's the risk people take when they follow the development
> code too closely.

Since I found it volatile in development, I have renamed it in my
personal packages to `rcd-dlet'.

My packages are with lexical binding. `dlet' is inevitable part of
template interpolation which is used to generate thousands of Internet
pages, e-mails, and too many PDf documents.

hyperscope.el:3113:	 (text (rcd-dlet ((hs::id id)
hyperscope.el:4515:    (rcd-dlet ((rcd::lisp (rcd-db-get-entry "markuptypes" "markuptypes_textlisp" markup hs-db))
hyperscope.el:4526:  (rcd-dlet ((hs::id id)
hyperscope.el:4545:      (rcd-dlet ((hs::markup-id (hyperscope-markup-language id))
hyperscope.el:4571:    (rcd-dlet ((hs::markup-id (hyperscope-markup-language id))
hyperscope.el:5772:  (rcd-dlet ((hs::markup-id (hyperscope-markup-language id)) 
hyperscope.el:5830:	     ;; 					       (rcd-dlet ((hd::is id)) (rcd-template-eval text)))
hyperscope.el:6819:	    (rcd-dlet ((hyperscope::variables (make-hash-table)))
hyperscope.el:6958:	      (rcd-dlet ((wrs::variables (make-hash-table :test 'equal))
hyperscope.el:7014:	  (rcd-dlet ((wrs::title title)
hyperscope.el:7116:		   (asciidoc (rcd-dlet ((hs:id id)) (rcd-template-eval asciidoc '("X" "X") hash)))
rcd-cf.el:6898:    (rcd-dlet ((wrs::width width)
rcd-cf.el:7840:	     (message (rcd-dlet ((rcd::hello-name name))
rcd-cf.el:9151:  (rcd-dlet ((wrs-text text))
rcd-cf.el:9310:				(rcd-dlet ((wrs::related-pages related-pages)
rcd-cf.el:9335:    (rcd-dlet ((rcd::name name)
rcd-cf.el:9381:    (rcd-dlet ((wrs::id page-id)
rcd-cf.el:9426:      (rcd-dlet ((wrs::text (rcd-template-eval wrs::text '("X" "X") wrs::variables))
rcd-cf.el:9429:	(rcd-dlet ((wrs::template (gethash "templates_template" wrs::template))
rcd-cf.el:10850:    (rcd-dlet ((rcd::name name)
rcd-cf.el:10998:      (rcd-dlet ((rcd::hello-name "Jean"))
rcd-cf.el:12307:    (rcd-dlet ((rcd::text text))
rcd-cf.el:12328:       (cond (template (rcd-dlet ((wrs::text text)
rcd-mailing.el:211:		 (message (rcd-dlet ((wrs::text message)
rcd-mailing.el:256:	   (expanded-body (rcd-dlet ((hello-name hello-name)
rcd-mailing.el:261:	   (html (rcd-dlet ((wrs::text (rcd-db-markupconversions-do expanded-body markup-input markup-output-html))
rcd-utilities.el:191:(defmacro rcd-dlet (binders &rest body)
rcd-utilities.el:1881:  (rcd-dlet ((wrs-processor "asciidoctor"))

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #23 received at 59333 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: Daan Ro <daanturo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 59333 <at> debbugs.gnu.org
Subject: Re: bug#59333: [PATCH] Define macro dlet*
Date: Sat, 19 Nov 2022 07:37:31 +0300

* Daan Ro <daanturo <at> gmail.com> [2022-11-17 10:42]:
> > dlet was new in Emacs 28, and the change you mention was done before
> > Emacs 28 was released.  So NEWS just mentions the introduction of
> > dlet, and that is enough.
> 
> Sorry it was my fault for not paying attention to the commit year (I thought
> that was August this year).
> 
> Therefore reverting it now must not be an option.
> 
> But I think let* is more useful than let in general for programming,
> as it let us create successive bindings and transform the flow of
> data, like the natural flow of thought.

In some cases I use `dlet' within my 'let*' to make certain
variables to be global as those variables are not found in the
main code, but in the external text. Those two functions are not
interchangeable for me. Replacing them does not work.

Example is below:

(let* ((text (rcd-dlet ((hs::id id)
			(hs::uuid (hyperscope-uuid id))) 
	       (rcd-template-eval text '("⟦" "⟧")))))
  (continue...))

There are three parts: main code, template and text. Main code
does the template interpolation by using text.

As text is separate from code and from the template, the main
code cannot know what exactly is evaluated during template
interpolation. Thus using lexical binding does not work well with
externally evaluated code.

--
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #26 received at 59333 <at> debbugs.gnu.org (full text, mbox):

From: Jean Louis <bugs <at> gnu.support>
To: daanturo <daanturo <at> gmail.com>
Cc: 59333 <at> debbugs.gnu.org
Subject: Re: bug#59333: [PATCH] Define macro dlet*
Date: Sat, 19 Nov 2022 07:47:16 +0300

* daanturo <daanturo <at> 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.

If I remember well, `dlet' was working just fine (as in the sense of
dlet*), and then because it was changed and made `dlet' behave not in
the sense of `dlet*', it did not work any more for me, so I have
renamed the old dlet, to my private function `rcd-dlet' to fix it's
behavior when developers changed the last line.

The last line of `dlet' is now:  (let ,binders ,@body))) while I need
it to be as below:      (let* ,binders ,@body)))

(defmacro rcd-dlet (binders &rest body)
  "Like `let*' but using dynamic scoping.

Argument BINDERS behaves similarly like `let' with the difference
that variables become global even under lexical scope.

Optional argument BODY will be executed."
  (declare (indent 1) (debug let))
  ;; (defvar FOO) only affects the current scope, but in order for
  ;; this not to affect code after the main `let' we need to create a new scope,
  ;; which is what the surrounding `let' is for.
  ;; FIXME: (let () ...) currently doesn't actually create a new scope,
  ;; which is why we use (let (_) ...).
  `(let (_)
     ,@(mapcar (lambda (binder)
                 `(defvar ,(if (consp binder) (car binder) binder)))
               binders)
     (let* ,binders ,@body)))


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Message #29 received at 59333 <at> debbugs.gnu.org (full text, mbox):

From: daanturo <daanturo <at> gmail.com>
To: Jean Louis <bugs <at> gnu.support>
Cc: 59333 <at> debbugs.gnu.org
Subject: Re: bug#59333: [PATCH] Define macro dlet*
Date: Sat, 19 Nov 2022 12:29:24 +0700

[Message part 1 (text/plain, inline)]

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 <at> 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.

[0001-Define-macro-dlet-asterisk.patch (text/x-patch, attachment)]

Message #36 received at 59333 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 59333 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, daanturo <daanturo <at> gmail.com>
Subject: Re: bug#59333: [PATCH] Define macro dlet*
Date: Thu, 24 Nov 2022 16:14:00 -0800

tags 59333 + wontfix
close 59333
thanks

Mattias Engdegård <mattiase <at> acm.org> writes:

> 17 nov. 2022 kl. 14.22 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:
>
>> Currently I see very few uses of `dlet`, so adding `dlet*`
>> seems overkill.
>
> I concur. (The proposed patch also appears incorrect, and lacks a test.)
> Anyone really needing a `dlet*` macro can easily implement one in terms of `dlet`.

So it sounds like this is not something that we don't want to do at this
time.  I'm therefore closing this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.