Re: policy, recommendations regarding `cl-*'

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> 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