bug#22291: 25.1.50; REGRESSION: Emacs 24.3 breaks loading cl-macs to get macro `case'

bug#22291: 25.1.50; REGRESSION: Emacs 24.3 breaks loading cl-macs to get macro `case'

[Drew Adams]

This regression was introduced in Emacs 24.3.  Prior to that, code could
use (require 'cl-macs) to have macros such as `case' provided at
runtime.

(eval-when-compile (require 'cl)) still works, of course.  But neither
(eval-when-compile (require 'cl-macs)) nor (require 'cl-macs) defines
macro `case', starting with Emacs 24.3.

This gratuitously breaks any existing code that loads cl-macs expecting
to get the definition of `case'.  This breakage should not be necessary.


In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
 of 2015-12-10
Bzr revision: 6148555ee5a3d0139ae517803718b3e0357933c7
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk --enable-checking=yes
 --enable-check-lisp-object-type --without-compress-install 'CFLAGS=-Og
 -ggdb3' LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

bug#22291: 25.1.50; REGRESSION: Emacs 24.3 breaks loading cl-macs to get macro `case'

[Eli Zaretskii]

> Date: Fri, 1 Jan 2016 19:23:03 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> 
> This regression was introduced in Emacs 24.3.  Prior to that, code could
> use (require 'cl-macs) to have macros such as `case' provided at
> runtime.
> 
> (eval-when-compile (require 'cl)) still works, of course.  But neither
> (eval-when-compile (require 'cl-macs)) nor (require 'cl-macs) defines
> macro `case', starting with Emacs 24.3.
> 
> This gratuitously breaks any existing code that loads cl-macs expecting
> to get the definition of `case'.  This breakage should not be necessary.

From NEWS.24, under "Changes in Specialized Modes and Packages in
Emacs 24.3":

  *** 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 `cl' definitions that had to use `foo*' to avoid conflicts with
  pre-existing Elisp entities.  These have been renamed to `cl-foo'
  rather than `cl-foo*'.

IOW, this was a deliberate change, and you should either use 'cl-case'
with Emacs versions since 24.3, or use 'cl' instead of 'cl-macs'.

OK?

bug#22291: 25.1.50; NOTABUG: Emacs 24.3 breaks loading cl-macs to get macro `case'

[Glenn Morris]

The only public entry points to the cl library are cl/cl-lib
(it was always so).
External code should not attempt to load any of the cl-foo submodules
that it happens to be divided into. For case, simply

(eval-when-compile (require 'cl))

bug#22291: 25.1.50; NOTABUG: Emacs 24.3 breaks loading cl-macs to get macro `case'

[Drew Adams]

> The only public entry points to the cl library are cl/cl-lib
> (it was always so).

What does that even mean?  What determines it; IOW, why do you say so?

> External code should not attempt to load any of the cl-foo submodules
> that it happens to be divided into.

Where is that stated, besides your statement of it now?  And what
would be the rationale for such a proscription?

bug#22291: 25.1.50; REGRESSION: Emacs 24.3 breaks loading cl-macs to get macro `case'

[Drew Adams]

> IOW, this was a deliberate change, and you should either use 'cl-case'
> with Emacs versions since 24.3, or use 'cl' instead of 'cl-macs'.

I know all of that.  Just because something was decided does not mean
that that decision was the best decision possible, or even wise.

This is a gratuitous change that breaks backward compatibility.  That's
the point.  Gratuitous - unnecessary.

Personally I tend to require `cl', and at compile-time only, to get
such macros.  But it is entirely reasonable that someone might require
`cl-macs' - at runtime or compile time - to get such a macro definition.

And if some user does not compile the code that requires the library
that provides the macro, then s?he will now get the entire `cl' at
runtime, instead of getting only the much-smaller `cl-macs' at runtime.

> OK?

Not IMHO.

bug#22291: 25.1.50; REGRESSION: Emacs 24.3 breaks loading cl-macs to get macro `case'

[Eli Zaretskii]

> Date: Sat, 2 Jan 2016 09:28:02 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 22291@debbugs.gnu.org
> 
> > IOW, this was a deliberate change, and you should either use 'cl-case'
> > with Emacs versions since 24.3, or use 'cl' instead of 'cl-macs'.
> 
> I know all of that.  Just because something was decided does not mean
> that that decision was the best decision possible, or even wise.
> 
> This is a gratuitous change that breaks backward compatibility.  That's
> the point.  Gratuitous - unnecessary.
> 
> Personally I tend to require `cl', and at compile-time only, to get
> such macros.  But it is entirely reasonable that someone might require
> `cl-macs' - at runtime or compile time - to get such a macro definition.
> 
> And if some user does not compile the code that requires the library
> that provides the macro, then s?he will now get the entire `cl' at
> runtime, instead of getting only the much-smaller `cl-macs' at runtime.
> 
> > OK?
> 
> Not IMHO.

So I guess we will have to agree to disagree on this one.

From my POV, this is not a bug, but a deliberate change that is well
documented.

Closing.

bug#22291: 25.1.50; REGRESSION: Emacs 24.3 breaks loading cl-macs to get macro `case'

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> Personally I tend to require `cl', and at compile-time only, to get
>> such macros.  But it is entirely reasonable that someone might require
>> `cl-macs' - at runtime or compile time - to get such a macro definition.
>> 
>> And if some user does not compile the code that requires the library
>> that provides the macro, then s?he will now get the entire `cl' at
>> runtime, instead of getting only the much-smaller `cl-macs' at runtime.
>> 
>> > OK?
>> 
>> Not IMHO.

> So I guess we will have to agree to disagree on this one.

> From my POV, this is not a bug, but a deliberate change that is well
> documented.

From the point of view of the bug report, I agree with Eli.

From the point of view of the issue, I agree with Drew. Drew, let's close this
as a bug, but open a new discussion on better organization of the CL stuff. We
should start the discussion on tangents, until we arrive at something
meaningful to bring to the developer's list.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2