policy, recommendations regarding `cl-*'

policy, recommendations regarding `cl-*'

[Drew Adams]

I have code that uses macros from cl*.el.  This code needs to work with multiple
Emacs versions.  It is not clear to me how, if at all, I should change it now.

NEWS provides no guidance, AFAICT.  It says only this:

 *** CL's main entry is now (require 'cl-lib).
 `cl-lib' is like the old `cl' except that it uses the namespace cleanly,
 i.e. all its definitions have the "cl-" prefix (and internal definitions use
 the "cl--" prefix).

 If `cl' provided a feature under the name `foo', then `cl-lib' provides it
 under the name `cl-foo' instead, with the exceptions of the few definitions
 that had to use `foo*' to avoid conflicts with pre-existing Elisp entities,
 which have not been renamed to `cl-foo*' but just `cl-foo'.

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

That's all well and good for Emacs Dev coders, but it does not really guide
users wrt code that must work with multiple Emacs versions.  And the CL manual
does not seem to reflect this change at all.  At least I find no guidance there
either about this.

I would expect to see a clear explanation, with recommendations, of migration
and multiple-version support - in NEWS, preferably.  That is normal for What's
New, README, or Release Changes documents for software.

For example, if I currently have (loop...), what do you recommend?  Replace it
by this?

 (if (fboundp 'cl-loop) (cl-loop...) (loop...))

And likewise for all the rest.

(Yes, I know that this is only a deprecation now, and not yet desupport.  I
would nevertheless like to know what you recommend for supporting multiple Emacs
versions.)

Re: policy, recommendations regarding `cl-*'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 25 Sep 2012 13:31:17 -0700
> 
> I would expect to see a clear explanation, with recommendations, of migration
> and multiple-version support - in NEWS, preferably.  That is normal for What's
> New, README, or Release Changes documents for software.
> 
> For example, if I currently have (loop...), what do you recommend?  Replace it
> by this?
> 
>  (if (fboundp 'cl-loop) (cl-loop...) (loop...))
> 
> And likewise for all the rest.
> 
> (Yes, I know that this is only a deprecation now, and not yet desupport.  I
> would nevertheless like to know what you recommend for supporting multiple Emacs
> versions.)

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.

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?

Re: policy, recommendations regarding `cl-*'

[Stefan Monnier]

Drew.  Just keep using (require 'cl) for code that needs to run in
Emacs<24.3 and move on.  Yes, I hope to remove cl.el at the some point.
Sadly, I know this time is not anywhere close.

As for "new stuff more compatible with CL but using the wrong name",
I do not know what you're referring to (you're using cl-loop as an
example, but loop is now an alias for cl-loop, so that can't be it), so
just be concrete (but brief) and maybe I can explain it.


        Stefan

RE: policy, recommendations regarding `cl-*'

[Drew Adams]

> Drew.  Just keep using (require 'cl) for code that needs to run in
> Emacs<24.3 and move on.  Yes, I hope to remove cl.el at the 
> some point.  Sadly, I know this time is not anywhere close.

OK, will do.  That is, (eval-when-compile (require 'cl)).
I do not use cl at runtime.

> As for "new stuff more compatible with CL but using the wrong name",
> I do not know what you're referring to (you're using cl-loop as an
> example, but loop is now an alias for cl-loop, so that can't 
> be it), so just be concrete (but brief) and maybe I can explain it.

I do not see anything in either of the two messages I sent that resembles the
phrase you quote or the terms it uses ("compatible"? "wrong name"?).  I have no
idea what that phrase means or where you got it.  AFAICT, it is not from me.  I
don't understand it, and I cannot answer you.  Perhaps you are really quoting
someone else?

Wrt `cl-loop' and `loop': As long as one is an alias for the other, I have no
problem using either.  Of course. 

What I do not think is a great idea is the deprecation.  (Was there even a
proposal about deprecation and a discussion of the proposal?)

As I made clear, I am in favor of having a separate "namespace"-clean library
that systematically uses the prefix `cl-'.  What I disagree is a good idea is to
_deprecate_ the longstanding Emacs versions that do not have such a prefix.

IOW, if the aim, as was expressed in the original discussion where you proposed
`cl-lib.el' and the prefix `cl-', is simply to give users a clean way to use
cl.el functions at runtime, then I'm all in favor of that, and I agree with the
prefixing.

That is very different from deprecating the cl.el stuff.  And that deprecation
is not just some vaguely "at some point" hope on your part - you are deprecating
it *now*.

And deprecation calls out for doc about how to move from the old to the new, as
I mentioned.  The CL manual and NEWS are silent on this, so far.  This too is
not great.  (I realize that we are not ready to release yet, so there is still
time to make this right.)

But above all I am specifically concerned about the macros, since those are what
I use (I do not use the functions at runtime).

Why on earth are you deprecating existing macros in favor of the same macros
with a `cl-' prefix?  I haven't seen an answer to that yet.  And I'm hoping you
will change your mind about it.  Again, I have no problem with "duplicating" the
macros via aliasing.  My problem is with their deprecation.

That is my concern for code that I maintain: just the macro names.  Above and in
the previous two messages, I've expressed additional concerns that do not
necessarily affect me directly - about the Emacs code organization and the
process of discussing, deprecating, and communicating compatibility/migration
information about deprecations.

But my immediate concern is maintaining code for multiple Emacs versions that
uses cl.el macros.

Re: policy, recommendations regarding `cl-*'

[Stefan Monnier]

> And deprecation calls out for doc about how to move from the old to
> the new, as I mentioned.

We'll do that when we move cl.el to lisp/obsolete/, which I expect is
still several years away.

> Why on earth are you deprecating existing macros in favor of the same
> macros with a `cl-' prefix?  I haven't seen an answer to that yet.

Various reasons, tho I don't think it matters much:
- why have the old names when you have the new names?
  [I know you'll say backward compatibility, but the question is meant in
  the long term.  cl.el is still kept for compatibility for now]
- several old names are actually problematic:
  - it starts with mild problems such as mapcar*, function* and friends
    where the * was needed just to avoid conflicts, where in the new
    names you can use the natural "cl-mapcar" rather than "cl-mapcar*".
  - then gets to the actual conflicts like dolist/dotimes (luckily
    push/pop has been fixed by extending Elisp's builtin push/pop to
    cover CL's semantics) which even recently brought real problems
    where eager macroexpansion failed for some files because
    substituting subr.el's dolist with CL's dolist creates a circular
    dependency between CL macroexp and gv (IIRC).

> And I'm hoping you will change your mind about it.

Not a chance.

> But my immediate concern is maintaining code for multiple Emacs versions that
> uses cl.el macros.

You're fighting a non-problem.


        Stefan

Re: policy, recommendations regarding `cl-*'

[Bastien]

On a related note, am I understanding right that functions
and macros from cl-macs.el will *not* trigger warnings?

For example, compiling a file with this

  (cl-position '1 '(0 1 2 3))
  (cl-defsubst test () (interactive) (message "blah"))

will warn about cl-position, not cl-defsubst.

Do I get it right?  Why is it so?

Thanks,

-- 
 Bastien

Re: policy, recommendations regarding `cl-*'

[Stefan Monnier]

> On a related note, am I understanding right that functions
> and macros from cl-macs.el will *not* trigger warnings?

Depends what kind of warning and in which circumstance.

> For example, compiling a file with this
>   (cl-position '1 '(0 1 2 3))
>   (cl-defsubst test () (interactive) (message "blah"))
> will warn about cl-position, not cl-defsubst.

I don't see any particular reason to have a warning for the above code,
unless of course you forgot the (require 'cl-lib) or you wrapped the
(require 'cl-lib) in an eval-when-compile.  So please say precisely
which warning you get and in which case.

        Stefan

Re: policy, recommendations regarding `cl-*'

[Bastien]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> On a related note, am I understanding right that functions
>> and macros from cl-macs.el will *not* trigger warnings?
>
> Depends what kind of warning and in which circumstance.

I have a test.el file with just this:

  (eval-when-compile (require 'cl))
  (cl-position '1 '(0 1 2 3))
  (cl-defsubst test () (message "blah"))

In dired, I byte-compile with `B' on the file.

>> For example, compiling a file with this
>>   (cl-position '1 '(0 1 2 3))
>>   (cl-defsubst test () (interactive) (message "blah"))
>> will warn about cl-position, not cl-defsubst.
>
> I don't see any particular reason to have a warning for the above code,
> unless of course you forgot the (require 'cl-lib) or you wrapped the
> (require 'cl-lib) in an eval-when-compile.  So please say precisely
> which warning you get and in which case.

With the recipe above, I get this warning:

Compiling file /home/guerry/test.el at Wed Sep 26 15:01:47 2012
test.el:1:2:Warning: function `cl-position' from cl package called at runtime

Why is there no warning about cl-defsubst?  cl-defsubst is defined in
cl-macs.el but I don't see where cl.el is unconditionnally requiring
cl-macs.

How to get rid of the warning about cl-position?  cl-seq.el doesn't
have any (provide 'cl-seq).

This is with GNU Emacs 24.2.50.2 (i686-pc-linux-gnu, GTK+ Version 3.4.4)
of 2012-09-20.

-- 
 Bastien

Re: policy, recommendations regarding `cl-*'

[Stefan Monnier]

>>> On a related note, am I understanding right that functions
>>> and macros from cl-macs.el will *not* trigger warnings?
>> Depends what kind of warning and in which circumstance.
> I have a test.el file with just this:
>   (eval-when-compile (require 'cl))
>   (cl-position '1 '(0 1 2 3))
>   (cl-defsubst test () (message "blah"))

There's a bug: at run time, CL will not be loaded, so cl-position
won't exist.
For cl-defsubst, that's not a problem, because it gets macroexpanded
away during compilation, so it's not needed at run-time.

IOW if you use CL functions, you need (require 'cl-lib) without wrapping
it in eval-when-compile.


        Stefan

Re: policy, recommendations regarding `cl-*'

[Bastien]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> There's a bug: at run time, CL will not be loaded, so cl-position
> won't exist.
> For cl-defsubst, that's not a problem, because it gets macroexpanded
> away during compilation, so it's not needed at run-time.
>
> IOW if you use CL functions, you need (require 'cl-lib) without wrapping
> it in eval-when-compile.

That's perfectly clear, thanks.

-- 
 Bastien

Re: policy, recommendations regarding `cl-*'

[Michael Welsh Duggan]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>>> On a related note, am I understanding right that functions
>>>> and macros from cl-macs.el will *not* trigger warnings?
>>> Depends what kind of warning and in which circumstance.
>> I have a test.el file with just this:
>>   (eval-when-compile (require 'cl))
>>   (cl-position '1 '(0 1 2 3))
>>   (cl-defsubst test () (message "blah"))
>
> There's a bug: at run time, CL will not be loaded, so cl-position
> won't exist.
> For cl-defsubst, that's not a problem, because it gets macroexpanded
> away during compilation, so it's not needed at run-time.
>
> IOW if you use CL functions, you need (require 'cl-lib) without wrapping
> it in eval-when-compile.

I use cl-delete-if in my .emacs.el file.  I have (require 'cl-lib) near
the top.  However, when I compile this, I still get warnings:

In add-unique:
.emacs.el:31:63:Warning: function `cl-delete-if' from cl package called at
    runtime

In md5i-save-undo-information:
.emacs.el:353:34:Warning: function `cl-remove-if' from cl package called at
    runtime

I thought that when using the renamed functions there weren't supposed
to be any warnings generated?

-- 
Michael Welsh Duggan
(mwd@cert.org)

Re: policy, recommendations regarding `cl-*'

[Stefan Monnier]

> I use cl-delete-if in my .emacs.el file.  I have (require 'cl-lib) near
> the top.  However, when I compile this, I still get warnings:
[...]
> In add-unique:
> .emacs.el:31:63:Warning: function `cl-delete-if' from cl package called at
>     runtime
[...]
> I thought that when using the renamed functions there weren't supposed
> to be any warnings generated?

And you thought right, that's a bug.  Could you re-report it to
bug-gnu-emacs so it gets a bug-number in the mean time (I can't fix it
just now)?


        Stefan

Re: policy, recommendations regarding `cl-*'

[Michael Welsh Duggan]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I use cl-delete-if in my .emacs.el file.  I have (require 'cl-lib) near
>> the top.  However, when I compile this, I still get warnings:
> [...]
>> In add-unique:
>> .emacs.el:31:63:Warning: function `cl-delete-if' from cl package called at
>>     runtime
> [...]
>> I thought that when using the renamed functions there weren't supposed
>> to be any warnings generated?
>
> And you thought right, that's a bug.  Could you re-report it to
> bug-gnu-emacs so it gets a bug-number in the mean time (I can't fix it
> just now)?

Done.  This is now bug #12539.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

RE: policy, recommendations regarding `cl-*'

[Drew Adams]

> > And deprecation calls out for doc about how to move from the old to
> > the new, as I mentioned.
> 
> We'll do that when we move cl.el to lisp/obsolete/, which I expect is
> still several years away.

Deprecation is typically a recommendation to use the new and not the old.  Hence
doc about migration/compatibility to help users do that.  This does not sound
much like a deprecation - perhaps it's only half-hearted.

> > Why on earth are you deprecating existing macros in favor 
> > of the same macros with a `cl-' prefix?  I haven't seen an
> > answer to that yet.
> 
> Various reasons, tho I don't think it matters much:
> - why have the old names when you have the new names?
>   [I know you'll say backward compatibility, but the question 
>   is meant in the long term.  cl.el is still kept for compatibility
>   for now]

I've already agreed that adding `cl-' aliases is not bad.  It's about the
macros.  Why deprecate them?

> - several old names are actually problematic:
>   - it starts with mild problems such as mapcar*, function* 
>     and friends where the * was needed just to avoid conflicts,
>     where in the new names you can use the natural "cl-mapcar"
>     rather than "cl-mapcar*".

So you use a prefix instead of a suffix to avoid conflicts.  Still not a reason
to deprecate the existing macro names.  (`mapcar(*)' is not a macro, BTW.)  

>   - then gets to the actual conflicts like dolist/dotimes (luckily
>     push/pop has been fixed by extending Elisp's builtin push/pop to
>     cover CL's semantics) which even recently brought real problems
>     where eager macroexpansion failed for some files because
>     substituting subr.el's dolist with CL's dolist creates a circular
>     dependency between CL macroexp and gv (IIRC).

That's a conflict within Emacs itself.  There I agree that something better is
needed.

There is no logical reason why Emacs subr.el needed to use the same name (e.g.
`dolist') for something that exists in Common Lisp and in cl.el with a different
meaning.  (And no, I don't think that Emacs had `dolist' etc. before Common Lisp
existed.)  But so be it - we are where we are.

The problem you point out is apparently not with the code that uses one `dolist'
or the other, but with the handling of library loading and eager macro
expansion.  If a user does not load cl then `dolist' should come from subr.el.

But I imagine that this might well become a headache at some level, and clearly
it is error prone - easy for a programmer to not know that some library loaded
by a user loads the cl version, etc.  So I can see your point here.

But that's an argument for deprecating those macros that present a problem
because of a conflict between the cl.el version and the subr.el version.  That
does not apply to macros like `loop' that do not suffer from that disease.  Why
have a blanket deprecation instead of doing the right thing case by case?

> > And I'm hoping you will change your mind about it.
> 
> Not a chance.
> 
> > But my immediate concern is maintaining code for multiple 
> > Emacs versions that uses cl.el macros.
> 
> You're fighting a non-problem.

I'm not fighting anything.  I asked for a recommendation for adapting existing
code, to which you suggested doing nothing and said that recommendations for
respecting this "deprecation" will come when the code is moved to `obsolete'.
So that is apparently the real moment of deprecation.  So why proclaim
deprecation (and even obsolescence) now and not then?

I would have preferred to see a discussion about such a deprecation before it
pounced on us fullblown.  But so be it.  (It's possible there was such a
discussion and I missed it.  But I haven't heard that asserted.)

Re: policy, recommendations regarding `cl-*'

[Stefan Monnier]

> Deprecation is typically a recommendation to use the new and not the
> old.  Hence doc about migration/compatibility to help users do that.
> This does not sound much like a deprecation - perhaps it's only
> half-hearted.

Definitely half-hearted: real deprecation would mean moving to
lisp/obsolete.  The only extent to which it's currently deprecated is
that I used the word "deprecated" in the NEWS file.
C-h f loop RET won't tell you that it's deprecated and neither will the
byte-compiler.

> I've already agreed that adding `cl-' aliases is not bad.  It's about the
> macros.  Why deprecate them?

Why should macros be treated differently?

>> - several old names are actually problematic:
>> - it starts with mild problems such as mapcar*, function* 
>> and friends where the * was needed just to avoid conflicts,
>> where in the new names you can use the natural "cl-mapcar"
>> rather than "cl-mapcar*".

> So you use a prefix instead of a suffix to avoid conflicts.

That's not the point.  The point is that "cl-" is used systematically
for every element, whereas "*" was only used in an ad-hoc manner for those
elements where the was a conflict and where the implementors decided the
conflict had to be solved by renaming.

> There is no logical reason why Emacs subr.el needed to use the same
> name (e.g.  `dolist') for something that exists in Common Lisp and in
> cl.el with a different meaning.

It's kept a subset of the CL meaning, hence the same name.
And being able to choose names freely in subr.el is the whole point of
not allowing the use of cl.el.

> The problem you point out is apparently not with the code that uses
> one `dolist' or the other, but with the handling of library loading
> and eager macro expansion.  If a user does not load cl then `dolist'
> should come from subr.el.

Yes, a package which uses subr.el's dolist will end up using CL's dolist
(against its wishes) if cl.el happens to be loaded.  This may cause
cl-macs to be loaded which in turn will cause other things to
be loaded.  So when you consider dependencies, any dolist use should be
considered as potentially using CL's dolist (and hence using `block'),
even if it sticks to subr.el's subset.

> But that's an argument for deprecating those macros that present a problem
> because of a conflict between the cl.el version and the subr.el version.

Yes, CL's dolist and dotimes are the parts of CL I hope to deprecate as
soon as possible.

> That does not apply to macros like `loop' that do not suffer from that
> disease.  Why have a blanket deprecation instead of doing the right
> thing case by case?

Because CL has tons of stuff and I don't have time to go one by one.
We can still move things back to "non-prefixed" on a case by case
basis anyway, now or in the future.  I first wanted to clean up
the namespace.

> code, to which you suggested doing nothing and said that recommendations for
> respecting this "deprecation" will come when the code is moved to `obsolete'.
> So that is apparently the real moment of deprecation.  So why proclaim
> deprecation (and even obsolescence) now and not then?

It's a change that will affect many packages, so I prefer getting people
to get used to the idea and maybe even start moving to cl-lib for those
rare packages where backward compatibility is not an issue.

> I would have preferred to see a discussion about such a deprecation before it
> pounced on us fullblown.  But so be it.  (It's possible there was such a
> discussion and I missed it.  But I haven't heard that asserted.)

I don't see the point of a discussion about it since it's currently
nothing more than a word in etc/NEWS, with no other concrete impact, it
just clarifies what's the intention behind cl-lib (i.e. it's not just
to have a version that's OK even at run-time, but really to replace the
old).


        Stefan

RE: policy, recommendations regarding `cl-*'

[Drew Adams]

> The only extent to which it's currently deprecated is
> that I used the word "deprecated" in the NEWS file.
> C-h f loop RET won't tell you that it's deprecated and 
> neither will the byte-compiler.

FWIW, I came across the change when looking at Emacs source code, not via NEWS.
I then looked in NEWS hoping to see what the change really amounted to.

Anyway, thanks for clarifying the aims and policy.

Re: policy, recommendations regarding `cl-*'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Tue, 25 Sep 2012 15:09:05 -0700
> 
> > 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.

If that ever happens in your lifetime, you can always add to your
packages a compatibility layer that simply introduces back the aliases
we have now.

Re: policy, recommendations regarding `cl-*'

[Stefan Monnier]

> If that ever happens in your lifetime, you can always add to your
> packages a compatibility layer that simply introduces back the aliases
> we have now.

Actually, I'm so anxious to get rid of cl.el that I already have a plan
for that: just move cl.el to GNU ELPA.


        Stefan

RE: policy, recommendations regarding `cl-*'

[Drew Adams]

> > 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.
> 
> If that ever happens in your lifetime,

Well, long life to you too, Eli!

> you can always add to your packages a compatibility layer
> that simply introduces back the aliases we have now.

Ugh.

Re: policy, recommendations regarding `cl-*'

[Jason Rumney]

"Drew Adams" <drew.adams@oracle.com> writes:

>> 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.

Deprecation generally means the feature will not be removed until the
old versions are well and truely gone.  When the feature is about to be
removed, you are sure to hear about it here, or by reading an
announcement in etc/NEWS.  At that time, you will probably want to clean
out the cruft to support long since unused versions of Emacs from your code.

Re: policy, recommendations regarding `cl-*'

[Helmut Eller]

On Tue, Sep 25 2012, Drew Adams wrote:

> I have code that uses macros from cl*.el.  This code needs to work
> with multiple
> Emacs versions.  It is not clear to me how, if at all, I should change
> it now.

This "let's deprecate cl" business is quite insane.  It has zero
benefits because the established names can't be used for new
functionality without breaking boatloads of code in the wild.  It
already breaks a lot of code and creates unnecessary work.  I'm
boycotting this madness until the maintainers come to senses.

Helmut