RE: policy, recommendations regarding `cl-*'

["Drew Adams" <drew.adams@oracle.com>]

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