GNU bug report logs - #65344
28.2; Unable to Edebug cl-flet form which uses argument destructuring

Previous Next

Package: emacs;

Reported by: Brandon Irizarry <brandon.irizarry <at> gmail.com>

Date: Wed, 16 Aug 2023 18:23:02 UTC

Severity: normal

Found in version 28.2

Fixed in version 30.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>, "brandon.irizarry <at> gmail.com" <brandon.irizarry <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>, "65344 <at> debbugs.gnu.org" <65344 <at> debbugs.gnu.org>
Subject: bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring
Date: Thu, 24 Aug 2023 05:16:04 +0200
Drew Adams <drew.adams <at> oracle.com> writes:

> IOW, let's not hope for perfect, and give up because
> things are already imperfect (that ship has sailed).
> Instead, why not declare that it's better to not add
> non-CL stuff to cl-*.el files, and work to keep it
> out.  Not adding more, and declaring that policy, is
> at least better than adding more with no such policy.
>
> Just one opinion.  We could improve things a bit here.

My opinion is different.  cl-lib enhancing Emacs Lisp well is more
important than emulating Common Lisp 100 percent perfectly - which is
impossible anyway (no multiple return values, etc.).  And we don't have
the manpower to separate cl-lib into two libraries - one with the goal
to be maximally Common Lisp compliant, the other being a maximally good
enhancement for Elisp.  So unless someone is willing to invest this not
small amount of work, now and in the future (and I want to ask: would
this be a good investment of time, given the huge amount of open real
bugs)...

... we have to live with the situation that we have only 1 library, and
only one definition for every CL thing.  And the compromise is that we
don't break CL semantics wherever possible, and try to add only stuff
that is more or less diagonal to the existing semantics.  And this is
the case apart from some corner cases that are negligible, compared to
the language features we don't provide at all.

I don't understand what your actual problems with this situation are.
The thing developed into a different direction than you expected, and,
IMO, became better, more useful for Emacs.  You like CL, ok, you are
nonetheless not disallowed to run Common Lisp on your computer or even
in Emacs.

So, what is goal, why is it better than what we have now, and how do you
want to reach that goal?


Michael.




This bug report was last modified 1 year and 261 days ago.

Previous Next


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