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

[Drew Adams]

> > If something is somewhat like a CL construct,
> > but it is intentionally different in some way
> > (and not just because we've implemented only
> > partial support for it), then why use the
> > prefix `cl-' for it?  Why not use the prefix
> > `el-' or whatever?
> 
> That would be much more confusing IMO.  `cl-flet' is not just "somewhat
> like a CL construct".  "cl inspired" would be a bad description.  The
> manual clearly describes the limits of the "emulation", and, as I said,
> even more limiting incompatibilities do not stem from such extensions.

You seem to be guessing that by "something" I
meant `cl-flet' or at least I meant to include
`cl-flet'.  I did not.

I was speaking generally - the "If something"
is key.

Yes, I can tell from the Subject that this
thread is specifically about `cl-flet'.  I
tried to make clear that my comment was not
really on-topic, but was more general: about
our handling of CL and non-CL stuff. 
 
> > Nothing says that Elisp needs to have the
> > same things as CL.  But why call something
> > different "CL support" or "CL emulation", and
> > use the same prefix, `cl-', that we use for
> > things that are really intended to emulate
> > CL constructs?
> 
> The library is somewhere between an "CL emulation" and a "CL inspired
> extension library".  It is hard to find a really good name and
> description.

Exactly my point.  Instead of "the library",
which is a congeries and can become a
catch-all, let's work toward having two (or
more, if needed) separate libraries: for
(1) CL emulation, however limited or complete
and (2) other, non-CL constructs, however
much they may have been inspired in some way
by something in CL.

> > It's like we have no guideline or map now.
> 
> Naming being hard or not satisfactory doesn't imply anything.  I doesn't
> tell what we must do.  It just means it is hard to find a "perfect for
> everybody" name.  That naming something is hard might mean that there is
> a problem with that thing, or it might mean nothing.

Agreed that naming is hard.  But that's not
what my point is about.  Currently, we don't
have two separate bins in which to place
things: (1) CL-emulation and (2) other.  So
there's no reflection at the name level that's
preceded by deciding _what_ something is: (1)
CL support or (2) non-CL.

> > To what avail?  There's no shortage of
> > prefixes and nothing forcing things with
> > different purposes or natures to be in the
> > same file.
> 
> Changing this prefix would cause work and trouble.

I wasn't speaking of changing any specific
name or its prefix.  I wasn't speaking of
`cl-flet', for example.  I was speaking in
general, proposing a policy of trying to
avoid mixing in stuff that doesn't support
our CL emulation with stuff that does.

> If you think it is worth it - what's your
> suggestion?  "el-" is much worse.

I don't care what the non-CL library or
libraries might be called, or what prefixes
they might use - other than not using `cl-'.

And it might well be that some such constructs
would belong in existing standard files.  And
maybe, as such, some might not need any prefix.

> What in `flet' is more "Emacs Lisp"y than in
> `let'?

Again, I haven't said a word about `flet' or
`let' or ANY specific `cl-*' construct.

Dunno what gave you that impression; apologies
if I said something that could be misread to
make someone think that.

As for `let': IIUC it's pretty close to the
`let' in CL now (but yes, we have buffer-local
etc.).  I also don't have a problem with Emacs
_not_ using any `cl-' prefix for something
that does the same as what's in CL.

We don't call our `if' `cl-if', but (I think?)
it's the same as the `if' of CL.  Likewise,
our `cond' etc.  And rightfully so.

> Everything in Emacs Lisp is Emacs
> Lisp.  The "Emacs Lisp" version of `flet'?  Of which `flet'?  Ahh - of
> the Common Lisp `flet' - but it's only 99.9% compatible, so we don't
> call it "cl-".

FWIW (as kinda said above), I'm OK with 99%
(or even less) support for some CL construct,
and I'm even OK with dropping the `cl-'
prefix.

The `cl-' prefix distinguishes something that
emulates a CL construct from something else
that might otherwise have the same name but
is not CL.

E.g., our regular `defun' is different from
`cl-defun'.

If we didn't have our own macro named `defun'
and we had only `cl-defun' then (IMO) it
would be OK to call that just `defun'.  And
for clarity - to let users know that it's
essentially CL `defun', we'd alias it to
`cl-defun'.

What I disagree with, as expressed in this
thread, is the addition to a `cl*.el' library
of something that's _not_ a CL construct, and
giving it a `cl-' prefix.  _Why do that?_
That's the question I asked - to what avail?

> This line of argument is not convincing me.  If a user has looked at the
> documentation (one has to anyway to get a start), the "cl-" is also
> hardly a source of confusion.  So I still don't see a relevant problem.

OK, so you don't see a problem.  Do you see
a reason why we would add some `cl-foobar' to
`cl-lib.el', if it's a function that has no
relation to Common Lisp?  Does it make any
sense to you that someone might expect it to
be housed elsewhere, with a different prefix
(or with no prefix)?

That's all I'm trying to say here.  Let's avoid
stuffing non-CL stuff in `cl*.el' files.  Is it
necessary to clean house wholesale, moving and
renaming things to fix this mixup?  No.  I'm
not proposing disruption or extra work - just a
recognition of a will to avoid adding not CL
stuff to `cl*.el' files and giving it prefix
`cl-'.  Nothing revolutionary or heavy-handed
intended.