RE: policy, recommendations regarding `cl-*'

[Drew Adams]

> I think, as long as you need to support versions of Emacs without
> cl-lib, just leave the code as it was, i.e. use 'loop' in the above
> example.

1. That's certainly what I am doing for now, at least.  But deprecation
typically expresses an intention to later desupport.  My question is really what
is recommended for supporting multiple Emacs releases when `loop' etc. are no
longer supported.

The point in separating deprecation from desupport in time is generally to give
users a heads-up and time to adapt.

In principle, users would want to start now to prepare for later desupport.  And
that is why software providers typically provide migration suggestions at the
time of deprecation, not just at the time of desupport.  For free software, at
least, it makes sense for such suggestions to include how to support multiple
releases.


2. It's not really clear to me either why it is the Emacs-traditional versions
that are being changed to have the prefix `cl-' now.  If it were the other way
around (give the new versions a prefix), then there would be no backward
compatibility problem.  No?

I'm probably missing something, but why is it important for Emacs to use a name
without a prefix such as `cl-' for something new, even if it might be closer to
the real Common Lisp meaning than is the old?

Why not continue to use, say, `loop' for what it has always been, and add a new
`super-duper-closer-to-c-l-loop' macro for a better, closer-to-the-real-thing
version?

I'm guessing there were packaging considerations involved, and I imagine they
had something to do with the requests by some people to use more cl.el stuff at
runtime.

But the overall picture is not real clear to me.  And as I said, neither NEWS
nor the CL manual helps in this regard.

Nor did searching emacs-devel for "cl-lib" help.  Searching more than subject
lines, I did however find a message that says this:

 >  > But I guess this is a common problem. Isn't there a common
 >  > solution?  I.e. is there a package containing the cl
 >  > functions with a proper name prefix like `cl-signum'?
 >
 SM> That's indeed the upcoming solution: as discussed somewhat
 SM> recently, I suggested we provide a new package `cl-lib'
 SM> which would be like CL but with a clean namespace (i.e.
 SM> everything starts with "cl-").  Then (require 'cl-lib)
 SM> would be perfectly acceptable.  cl.el would become a file
 SM> that just provides a bunch of aliases for backward
 SM> compatibility purposes.

That just states what was done, without much rationale.  And it says nothing
about deprecation.  (But in retrospect you can read a lot into that last
sentence.)  I must have missed the discussion that led to that decision.

I do see this supportive reply - by me - to an earlier thread:

SM> I think a first step is to provide a new package `cl-lib' 
SM> which would provide the CL functions (i.e. all those functions
SM> people seem to like but can't use because we disallow CL at
SM> runtime) under a clean "cl-" prefix.  This would allow all of
SM> CL to be used (either via (require 'cl-lib) or (eval-when-compile
SM> (require 'cl))) and would hence address the most pressing issues.
D> 
D> 1+
D> 
D> (But I don't see how (eval-when-compile (require 'cl))) would 
D> allow all of CL to be used, unless you meant only at compile time.)
D> 
D> That also has the advantage of skirting, for now, (a) the 
D> problem of conflicts with Emacs stuff with the same name and
D> (b) the work needed to replace the more limited Emacs stuff that
D> has the same name.

But again, there was nothing there about _deprecation_.  I thought we were
discussing only adding an additional library with the `cl-' prefix, for those
who wanted to use CL functions at runtime.  I am in favor of that, as I
indicated.

What was discussed there does not imply that someone would need to change their
code because we also intend to desupport `remove-if' etc. in favor of
`cl-remove-if' etc.  But that's apparently I'm seeing now as the real intention.

This, in NEWS, is pretty clear in stating that we are in fact _deprecating_
`remove-if', `loop', and so on:

  The old `cl' is now deprecated and is just a bunch of
  aliases that provide the old non-prefixed names.

(Notice how similar that "bunch of aliases" part is to the previous vague
statement, above?  But now we've added "is now deprecated and"!)

I completely missed the discussion (if it existed) that led to that decision.
What the reason was given for deprecating?

More importantly (for me): What I use are _macros_, like `loop'.  I have
respected the guideline to avoid using CL functions at runtime.

So why on earth are we also deprecating macros `loop' etc. in favor of macros
`cl-loop' etc.?  That's what I really don't get.  Why should I need to change
code that uses those longstanding macros, even if new, improved, less limited
ones might be made available?

For something like this, I would have expected at least some kind of an
announcement mail, explaining the design goal and the implemented solution to
meet it.  (And I would have preferred a discussion that led up to a decision.)

What am I missing?  What's the point?  What problem are we trying to solve, and
how does this deprecation help us solve it?


3. Coming back to my original question: Assuming that I _will_ need to change
code that uses `loop' etc., just what code changes are recommended, to allow
users like me to continue to support multiple Emacs versions?

I will do nothing for now, of course, as Eli suggests.  But what guidelines are
there for where we're headed?