Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26.

Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26.

[Stefan Monnier]

Hi Alan.

>     Make CC Mode load cl-lib rather than cl in Emacs 26.

Great.  Could you tell us why you go through all that trouble instead of
just always using cl-lib (which has been tested to work in Emacsen as
old as Emacs-21 and XEmacs-21.4)?  That would make you free to use any
cl-lib functions and macros without having to add matching c--* macros.


        Stefan

Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26.

[Alan Mackenzie]

Hello, Stefan.

On Sun, Jun 25, 2017 at 17:44:04 -0400, Stefan Monnier wrote:
> Hi Alan.

> >     Make CC Mode load cl-lib rather than cl in Emacs 26.

> Great.  Could you tell us why you go through all that trouble instead of
> just always using cl-lib (which has been tested to work in Emacsen as
> old as Emacs-21 and XEmacs-21.4)?

cl-lib doesn't exist in those older Emacsen, neither does it exist in
XEmacs.  So doing what you suggest isn't a sensible thing to do.

> That would make you free to use any cl-lib functions and macros
> without having to add matching c--* macros.

The macros are necessitated by, amongst other things, name changes in
functions, some of which have had traditionally approved names for
decades.  (I have a copy of the Lisp Machine Manual from the 1980s to
back this up.)

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26.

[Stefan Monnier]

> cl-lib doesn't exist in those older Emacsen, neither does it exist in
> XEmacs.  So doing what you suggest isn't a sensible thing to do.

Lots of Emacs packages rely on cl-lib while supporting older Emacsen
as well.  There are trade-offs, admittedly, but calling it "not
sensible" is like me saying that your choice is ridiculous.

My question was specifically to understand which part of the trade-offs
made you choose one option over the other.

>> That would make you free to use any cl-lib functions and macros
>> without having to add matching c--* macros.
> The macros are necessitated by, amongst other things, name changes in
> functions, some of which have had traditionally approved names for
> decades.  (I have a copy of the Lisp Machine Manual from the 1980s to
> back this up.)

Many of your c--* macros are there to choose between the `cl` name or
the `cl-lib` name, and every new macro/function you want to use from
cl/cl-lib will require another one of those macros.

Using cl-lib unconditionally would eliminate this need.


        Stefan

Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26.

[Alan Mackenzie]

Hello, Stefan.

On Mon, Jun 26, 2017 at 13:56:46 -0400, Stefan Monnier wrote:
> > cl-lib doesn't exist in those older Emacsen, neither does it exist in
> > XEmacs.  So doing what you suggest isn't a sensible thing to do.

> Lots of Emacs packages rely on cl-lib while supporting older Emacsen
> as well.  There are trade-offs, admittedly, but calling it "not
> sensible" is like me saying that your choice is ridiculous.

> My question was specifically to understand which part of the trade-offs
> made you choose one option over the other.

When a package relies on another package which is not part of the user's
Emacs, that forces that user either to search for and download that
other package, or to give up using the first package.  Both options are
likely to cause irritation and anger.

Doing so is unacceptable, IMAO, because it transfers effort from the
maintainer to the user.  The maintainer should do everything sensible to
smooth the way for his users.

> >> That would make you free to use any cl-lib functions and macros
> >> without having to add matching c--* macros.
> > The macros are necessitated by, amongst other things, name changes in
> > functions, some of which have had traditionally approved names for
> > decades.  (I have a copy of the Lisp Machine Manual from the 1980s to
> > back this up.)

> Many of your c--* macros are there to choose between the `cl` name or
> the `cl-lib` name, and every new macro/function you want to use from
> cl/cl-lib will require another one of those macros.

Yes.  One way to reduce this burden would be to make the traditional
names of these functions, without the "cl-" prefix, of equal status to
those with the prefix.

> Using cl-lib unconditionally would eliminate this need.

At great cost, as outlined above.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26.

[Stefan Monnier]

> When a package relies on another package which is not part of the user's
> Emacs, that forces that user either to search for and download that
> other package, or to give up using the first package.  Both options are
> likely to cause irritation and anger.

As you know, there are other options.  E.g. to distribute that other
package (cl-lib) along with yours.  Or to distribute your package via
a system which will take care of "search for and download" (e.g. ELPA).

Bundling cl-lib with your "manually installed" cc-mode package should be
pretty easy.  I'd be all too happy to help you with it, if that can sway you.

> Yes.  One way to reduce this burden would be to make the traditional
> names of these functions, without the "cl-" prefix, of equal status to
> those with the prefix.

Ah, yes, that discussion.  It's hard to please everyone.

I personally do not care to solve this 3-letter "problem", all that
mattered to me was to have access to all of CL at runtime (and maybe
even preloaded at some point in the future).

To me, it's an example where emacs-devel managed to negotiate a fairly
good compromise.


        Stefan

Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26.

[Alan Mackenzie]

Hello, Stefan.

On Mon, Jun 26, 2017 at 15:58:27 -0400, Stefan Monnier wrote:
> > When a package relies on another package which is not part of the user's
> > Emacs, that forces that user either to search for and download that
> > other package, or to give up using the first package.  Both options are
> > likely to cause irritation and anger.

> As you know, there are other options.  E.g. to distribute that other
> package (cl-lib) along with yours.  Or to distribute your package via
> a system which will take care of "search for and download" (e.g. ELPA).

The first would cause irritation to the user.  The second is simply not
the way CC Mode is distributed.

> Bundling cl-lib with your "manually installed" cc-mode package should be
> pretty easy.  I'd be all too happy to help you with it, if that can sway you.

Talk about taking a sledgehammer to crack a nut!

> > Yes.  One way to reduce this burden would be to make the traditional
> > names of these functions, without the "cl-" prefix, of equal status to
> > those with the prefix.

> Ah, yes, that discussion.  It's hard to please everyone.

No, not really.  Leaving the traditional names in place, producing no
compiler warnings, would have pleased more than what was done.

> I personally do not care to solve this 3-letter "problem", all that
> mattered to me was to have access to all of CL at runtime (and maybe
> even preloaded at some point in the future).

That is clear.  Other things, such as the consistency and compatibility
of function names, mattered to other people.

> To me, it's an example where emacs-devel managed to negotiate a fairly
> good compromise.

Funnily enough, I don't remember any negotiation, or even discussion
about the matter on emacs-devel before this change happened.  The extra
macros in CC Mode are one of the consequences.  I would really rather
not have had to spend time on this.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > When a package relies on another package which is not part of the user's
  > Emacs, that forces that user either to search for and download that
  > other package, or to give up using the first package.

Packages that are in Emacs should not ever depend on packages that are
outside Emacs.  If they do, it is a bug.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: [Emacs-diffs] master b0042b7: Make CC Mode load cl-lib rather than cl in Emacs 26.

[Stefan Monnier]

>> As you know, there are other options.  E.g. to distribute that other
>> package (cl-lib) along with yours.  Or to distribute your package via
>> a system which will take care of "search for and download" (e.g. ELPA).
> The first would cause irritation to the user.

Hmm... sorry, I don't see why that would cause irritation.
AFAICT the user would be blissfully unaware.  I doubt many of your users
would notice an additional 13KB file in your package.

> The second is simply not the way CC Mode is distributed.

I understand you want to support users of Emacsen that don't have
package.el, and that makes sense, indeed.  I mentioned it, because
I think it should be fairly easy to also distribute CC-mode via GNU
ELPA with very little extra work (the package would be built directly
from emacs.git, like we do for python.el, soap-client, and a few
more).

But yes, whether we do that or not doesn't make a difference for the
case of users of Emacsen without package.el (i.e. Emacs-23 and XEmacs).

>> Bundling cl-lib with your "manually installed" cc-mode package should be
>> pretty easy.  I'd be all too happy to help you with it, if that can sway you.
> Talk about taking a sledgehammer to crack a nut!

I agree that if you look at it as "adding a 13KB file" vs "add a few
(defmacro ... (if (eq c--cl-library ...)))", the choice may sound like
a sledgehammer, but the way I look at it, cl-lib.el is a file that's
already written and hasn't needed any maintenance since Feb-2014,
so you can take it as a black box.

>> Ah, yes, that discussion.  It's hard to please everyone.
> No, not really.  Leaving the traditional names in place, producing no
> compiler warnings, would have pleased more than what was done.

I see we agree ("more than" is not "everyone").

> Funnily enough, I don't remember any negotiation, or even discussion
> about the matter on emacs-devel before this change happened.  The extra
> macros in CC Mode are one of the consequences.  I would really rather
> not have had to spend time on this.

IIUC, the introduction of cl-lib is the result of the thread that
started with
https://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00175.html
This other thread is also related:
https://lists.gnu.org/archive/html/emacs-devel/2012-04/msg00245.html

But it is also the result of many earlier discussions asking for the
same thing.  Again and again, people asked to get access to all of CL's
functionality in Emacs (i.e. including CL's functions at runtime) and it's
always been rejected until we came up with cl-lib (and took advantage of
it to move several CL features, like setf, into core at the same time).

I have no intention to claim it's the perfect solution.  I'm pretty sure
it was noone's favorite solution, but my impression after 5 years is
that most people think it was an improvement (in large part thanks to
the cl-lib.el forward compatibility library which significantly eases up
the transition, although you don't want to use).


        Stefan