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


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

From: Drew Adams <drew.adams <at> oracle.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,
 "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: RE: [External] : bug#65344: 28.2; Unable to Edebug cl-flet form which
 uses argument destructuring
Date: Wed, 23 Aug 2023 14:23:29 +0000
> >> The root of this is the old discussion of how strictly cl-lib should
> >> follow the Common Lisp originals.  We will not pacify this discussion.
> >> I think we found a good compromise in most cases, even when it is not
> >> the optimum for everyone.
> >
> > FWIW.
> >
> > Dunno which part(s) of the people I fall in, but my
> > opinion is that we should have separated, and we
> > still should try to separate (1) actual Common Lisp
> > emulation/reproduction/whatever-you-want-to-call-it,
> > which should be quite faithful to the standard, from
> > (2) non-CL constructs (functions, variables, macros,
> > special forms) that might seem a bit CL-like or that
> > might share some of the underlying implementation
> > with some of #1.
> 
> Agree 100&, but that ship seems to have saild.

I think it's (at least at this point) about deciding
and stating the intention.  At first there we none
or few non-CL things offered in the cl-*.el code.
Then a very few more.  Then a bunch more.  If no
intention is declared that just adding non-CL stuff
almost/seemingly willy-nilly to cl-*.el is OK, such
addition might well be increasingly likely.

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.




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.