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

[Michael Heerdegen]

Drew Adams <drew.adams@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.