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

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

bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destr


From: Brandon Irizarry
Subject: bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring
Date: Tue, 22 Aug 2023 17:06:24 -0400

Hi all,

First, thanks for all the attention this has received. Eli, your comments are duly noted.

Trying my best to follow this thread, I took the patch submitted by Gerd, pasted it in my scratch buffer, renamed the macro 'my-cl-flet', but switched the order of the two '&define' clauses. I evaluated this macro and started using it on some small test cases, which check out. I believe I may merely be echoing Gerd's comment about exchanging the two debug specs, but I wanted to flesh this aspect out a bit more thoroughly in case. Note that I've used Org source blocks (which I've noticed people have been doing), since I suspect people are reading this thread in Emacs itself, and can subsequently avail themselves of this format.

Under 'emacs -Q':

#+begin_src emacs-lisp
(require 'cl-macs)

;; insert 'my-cl-flet' macro definition here

(my-cl-flet ((cool-fn ((min max))
                      (cons min max)))
  (cool-fn '(2 3)))
#+end_src

Edebug here runs as smooth as butter. Nice!

Next, I tried another example mentioned in this thread:

#+begin_src emacs-lisp
(defun make-fun (n)
  (message "the function")
  (lambda () n))

(defvar k 17)

(my-cl-flet ((a (make-fun k))) ;; `make-fun' call not instrumented
  (a))
#+end_src

Again, everything looks good. Finally, a more conventional example:

#+begin_src emacs-lisp
(my-cl-flet ((fn (a b)
                 (cons a b)))
  (fn 1 2))
#+end_src

Works out, as expected. So it looks like we may have a happy ending after all?

WDYT?

On Tue, Aug 22, 2023 at 4:05 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
Michael Heerdegen <michael_heerdegen@web.de> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> I wonder if this isn't a bug in cl-flet itself.  If you change the names
>> a bit, this is
>>
>> (cl-flet ((fn (a b)))
>>   ...)
>>
>> which is a perfectly valid local definition of FN with two parameter A
>> and B, returning nil in CL.  It signals an error in Emacs which I'd
>> consider a bug.
>
> It's a known limitation, AFAIR.  It's more important to support the
> (SYMBOL EXPR) than this corner case, and we don't want to guess "what is
> meant", so a binding of two elements is always interpreted this way in
> Elisp.  This problem has been discussed a while ago.

That's quite unfortunate :-(.  I wish that whole extension would be at
least be deprecated.

I'll exchange the two debug specs then.  ATM, I don't see how to test
that though.  That's also unfortunate.

> Hmm, right...but where did I see it.  Oh, I remember, it was
> `cl-defmethod' that supports such names.

Looks like it does, indeed, by constructing a symbol.  One couldn't tell
from the doc string :-).

reply via email to

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