GNU bug report logs - #66342
Quote cl-generic-current-method-specializers

Previous Next

To reply to this bug, email your comments to 66342 AT debbugs.gnu.org.

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

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

From: Thuna <thuna.cing <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Quote cl-generic-current-method-specializers
Date: Wed, 04 Oct 2023 16:18:20 +0200

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

Currently, cl-generic-current-method-specializers expands into an alist
of the form ((ARG . TYPE)...).  The patch I provide quotes this so that
it can serve as a proper sexp.

Without quoting, this expansion is a bad sexp that, when evaluated,
results in an error.  If quoted, the form will simply not macroexpand,
and any other method causes it to be evaluated after expanding.  As it
relies on the cl-defmethod's context, I see no obvious and/or convenient
ways to use macroexpand to get the result unevaluated.

A quick grep brought up no uses of this macro, so I feel that this
change shouldn't effect many people, if any at all, although feel free
to correct me if this is not the case.

[0001-Quote-cl-generic-current-method-specializers-inside-.patch (text/x-patch, attachment)]

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Thuna <thuna.cing <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 66342 <at> debbugs.gnu.org
Subject: Re: bug#66342: Quote cl-generic-current-method-specializers
Date: Tue, 11 Feb 2025 20:17:28 -0800

Thuna <thuna.cing <at> gmail.com> writes:

> Currently, cl-generic-current-method-specializers expands into an alist
> of the form ((ARG . TYPE)...).  The patch I provide quotes this so that
> it can serve as a proper sexp.
>
> Without quoting, this expansion is a bad sexp that, when evaluated,
> results in an error.  If quoted, the form will simply not macroexpand,
> and any other method causes it to be evaluated after expanding.  As it
> relies on the cl-defmethod's context, I see no obvious and/or convenient
> ways to use macroexpand to get the result unevaluated.
>
> A quick grep brought up no uses of this macro, so I feel that this
> change shouldn't effect many people, if any at all, although feel free
> to correct me if this is not the case.
>

Stefan M, could you please take a look at this patch?

>
> From a5b3065b8db59570cd98e8799c0ba0b0c46b9d6f Mon Sep 17 00:00:00 2001
> From: Thuna <thuna.cing <at> gmail.com> Date: Sun, 1 Oct 2023 21:15:29
> +0200 Subject: [PATCH] Quote cl-generic-current-method-specializers
> inside method body
>
> * lisp/emacs-lisp/cl-generic.el (cl--generic-lambda): Quote spec-args
> when using cl-generic-current-method-specializers inside a method
> body.
> ---
>  lisp/emacs-lisp/cl-generic.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lisp/emacs-lisp/cl-generic.el b/lisp/emacs-lisp/cl-generic.el
> index dec14bd5df6..a938195f097 100644
> --- a/lisp/emacs-lisp/cl-generic.el
> +++ b/lisp/emacs-lisp/cl-generic.el
> @@ -393,7 +393,7 @@ cl-generic-define-context-rewriter
>                    (cl--generic-split-args args))
>                   (fun `(cl-function (lambda ,plain-args ,@body)))
>                   (macroenv (cons `(cl-generic-current-method-specializers
> -                                   . ,(lambda () spec-args))
> +                                   . ,(lambda () (list 'quote spec-args)))
>                                   macroexpand-all-environment)))
>        (require 'cl-lib)        ;Needed to expand `cl-flet' and `cl-function'.
>        (when (assq 'interactive body)

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Thuna <thuna.cing <at> gmail.com>
Cc: 66342 <at> debbugs.gnu.org
Subject: Re: bug#66342: Quote cl-generic-current-method-specializers
Date: Fri, 14 Feb 2025 17:16:40 -0500

Hi,

> Currently, cl-generic-current-method-specializers expands into an alist
> of the form ((ARG . TYPE)...).  The patch I provide quotes this so that
> it can serve as a proper sexp.

Interesting.  Out of curiosity, where/how did you bump into this?

> Without quoting, this expansion is a bad sexp that, when evaluated,
> results in an error.

Indeed, it was never meant to be inserted as-is in the macro-expanded
code, instead the idea was that a macro could use

    (macroexpand '(cl-generic-current-method-specializers)
                 macroexpand-all-environment)

to collect type information about the variables to decide how to
generate its code.  This was not very well thought out (e.g. this typing
information may be invalid if the method mutates those vars) and AFAIK
it's never been used anywhere.

Maybe it's best to get rid of it?


        Stefan

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 66342 <at> debbugs.gnu.org, Thuna <thuna.cing <at> gmail.com>
Subject: Re: bug#66342: Quote cl-generic-current-method-specializers
Date: Sat, 1 Mar 2025 19:41:08 -0800

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Hi,
>
>> Currently, cl-generic-current-method-specializers expands into an alist
>> of the form ((ARG . TYPE)...).  The patch I provide quotes this so that
>> it can serve as a proper sexp.
>
> Interesting.  Out of curiosity, where/how did you bump into this?
>
>> Without quoting, this expansion is a bad sexp that, when evaluated,
>> results in an error.
>
> Indeed, it was never meant to be inserted as-is in the macro-expanded
> code, instead the idea was that a macro could use
>
>     (macroexpand '(cl-generic-current-method-specializers)
>                  macroexpand-all-environment)
>
> to collect type information about the variables to decide how to
> generate its code.  This was not very well thought out (e.g. this typing
> information may be invalid if the method mutates those vars) and AFAIK
> it's never been used anywhere.
>
> Maybe it's best to get rid of it?

If it's not useful, and anyways not used by anyone, I think it's better
to get rid of it.

Thuna, would you like to propose a patch that does that?

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

From: Thuna <thuna.cing <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>, Stefan Monnier
 <monnier <at> iro.umontreal.ca>
Cc: 66342 <at> debbugs.gnu.org
Subject: Re: bug#66342: Quote cl-generic-current-method-specializers
Date: Tue, 04 Mar 2025 22:28:12 +0100

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

> If it's not useful, and anyways not used by anyone, I think it's better
> to get rid of it.
>
> Thuna, would you like to propose a patch that does that?

Hm, I still think it's a shame, but sure.  Something like the attached
patch should do the trick, though I've not tested it in the slightest.

[0001-Remove-cl-generic-current-method-specializers.patch (text/x-patch, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Thuna <thuna.cing <at> gmail.com>
Cc: Stefan Kangas <stefankangas <at> gmail.com>, 66342 <at> debbugs.gnu.org
Subject: Re: bug#66342: Quote cl-generic-current-method-specializers
Date: Tue, 04 Mar 2025 17:15:07 -0500

>> Thuna, would you like to propose a patch that does that?
> Hm, I still think it's a shame, but sure.

Which brings back my first question:

    Interesting.  Out of curiosity, where/how did you bump into this?


- Stefan

Previous Next

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