bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Drew Adams]

In our `cl*.el' libraries we have some user-facing `cl-*' macros etc.
that do not correspond to anything in Common Lisp.  This seems
misguided.

We see this in node (cl) `Modify Macros', for example:

 "The following macros were invented for this package; they have no
  analogues in Common Lisp."

Why add them to a package that is for Common Lisp functionality (it is
"The GNU Emacs Common Lisp emulation package") if they are not part of
Common Lisp?

This is quite misleading, and it has led some people to think that
`letf' etc. are in fact part of Common Lisp.  Please consider renaming
these without the `cl-' prefix and moving them to a different library,
whose name does not start with `cl'.

In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
 of 2015-02-27 on LEG570
Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs'

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Eli Zaretskii]

> Date: Sun, 8 Mar 2015 11:02:33 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
>  of 2015-02-27 on LEG570
> Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7
  ^^^^^^^^^^^^^

Dani, what's this "bzr revision" thing about?  Do you see that on your
machine as well?

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

On 03/08/2015 11:02 AM, Drew Adams wrote:
> In our `cl*.el' libraries we have some user-facing `cl-*' macros etc.
> that do not correspond to anything in Common Lisp.  This seems
> misguided.
> 
> We see this in node (cl) `Modify Macros', for example:
> 
>  "The following macros were invented for this package; they have no
>   analogues in Common Lisp."
> 
> Why add them to a package that is for Common Lisp functionality (it is
> "The GNU Emacs Common Lisp emulation package") if they are not part of
> Common Lisp?
> 
> This is quite misleading, and it has led some people to think that
> `letf' etc. are in fact part of Common Lisp.  Please consider renaming
> these without the `cl-' prefix and moving them to a different library,
> whose name does not start with `cl'.

Even cl functions that have the same names as functions in Common Lisp
don't always have the same features or semantics. I don't think it's
very important that the cl package mirror Common Lisp.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Drew Adams]

> Even cl functions that have the same names as functions in Common Lisp
> don't always have the same features or semantics. I don't think it's
> very important that the cl package mirror Common Lisp.

That is something quite different.  Those differences are pointed
out, and the aim is to emulate Common Lisp, however imperfectly
we might be able to (or might want to) do so at any given time.

There is no reason to misleadingly add stuff to our emulation
library that has no counterpart is Common Lisp - is not
emulating anything there.  It is even worse to use names that
make it look as if these do correspond to Common Lisp things.

It is perfectly fine for Emacs to add things that Common Lisp
does not have/do.  But it should add them elsewhere from the
`cl*.el' files, and document them elsewhere than in manual CL.

These are *Emacs* things that have nothing to do with Common Lisp.

If you start adding non Common-Lisp stuff to `cl*.el', then where
will you stop?  What will be your criteria for adding them to
`cl*.el'?

If they do not emulate something in Common Lisp then they belong
elsewhere from `cl*.el' (this should be obvious, I think).

We are not redesigning Common Lisp or pretending to do so.

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Dani Moncayo]

>> In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
>>  of 2015-02-27 on LEG570
>> Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7
>   ^^^^^^^^^^^^^
>
> Dani, what's this "bzr revision" thing about?

I don't know.

> Do you see that on your
> machine as well?

No, I see this:

  In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
   of 2015-02-27 on LEG570
  Repository revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7
  Windowing system distributor `Microsoft Corp.', version 6.3.9600
  Configured using:
   `configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs'

-- 
Dani Moncayo

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]

On 03/08/2015 11:46 AM, Drew Adams wrote:
>> Even cl functions that have the same names as functions in Common Lisp
>> don't always have the same features or semantics. I don't think it's
>> very important that the cl package mirror Common Lisp.
> 
> That is something quite different.  Those differences are pointed
> out, and the aim is to emulate Common Lisp, however imperfectly
> we might be able to (or might want to) do so at any given time.
> 
> There is no reason to misleadingly add stuff to our emulation
> library that has no counterpart is Common Lisp - is not
> emulating anything there.  It is even worse to use names that
> make it look as if these do correspond to Common Lisp things.
> 
> It is perfectly fine for Emacs to add things that Common Lisp
> does not have/do.  But it should add them elsewhere from the
> `cl*.el' files, and document them elsewhere than in manual CL.

Why? Some things (like letf) are just natural extensions of facilities
we got from Common Lisp. Keep in mind that they didn't start out under
the cl namespace either. They were just there along with everything else
when we created cl-lib.

I don't think you've explained the downside of extending CL in the cl-
namespace. You've articulated an aesthetic point, but I don't see any
negative technical consequences.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Eli Zaretskii]

> Date: Sun, 8 Mar 2015 20:06:44 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>, 20056@debbugs.gnu.org
> 
> >> In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
> >>  of 2015-02-27 on LEG570
> >> Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7
> >   ^^^^^^^^^^^^^
> >
> > Dani, what's this "bzr revision" thing about?
> 
> I don't know.
> 
> > Do you see that on your
> > machine as well?
> 
> No, I see this:
> 
>   In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
>    of 2015-02-27 on LEG570
>   Repository revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7
>   Windowing system distributor `Microsoft Corp.', version 6.3.9600
>   Configured using:
>    `configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs'

Thanks, I guess there's some subtle bug that only rears its head when
git the executable is not around.

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Drew Adams]

> > There is no reason to misleadingly add stuff to our emulation
> > library that has no counterpart is Common Lisp - is not
> > emulating anything there.  It is even worse to use names that
> > make it look as if these do correspond to Common Lisp things.
> >
> > It is perfectly fine for Emacs to add things that Common Lisp
> > does not have/do.  But it should add them elsewhere from the
> > `cl*.el' files, and document them elsewhere than in manual CL.
> 
> Why? Some things (like letf) are just natural extensions of
> facilities we got from Common Lisp.

They may be natural extensions of Common Lisp for you, but that
does not make them Common Lisp, and it does not make them natural
extensions of Common Lisp for Common Lisp's designers.

We are not designing or extending Common Lisp.  That would be
pretentious.  We are designing Emacs Lisp.

It is perfectly fine to extend or redesign Emacs Lisp any way we
like.  And we can take whatever we want from Common Lisp and do
whatever we want with it.  We need not try to emulate any given
Common-Lisp function or macro.  But the things we put in the
Common-Lisp emulation package should be emulations of Common Lisp
things, IMO - things designed by the Common-Lisp designers for
Common Lisp.

It is not appropriate to add non Common-Lisp things to our
emulation of Common Lisp.  That's all.

> Keep in mind that they didn't start out under the cl namespace
> either. They were just there along with everything else
> when we created cl-lib.

Yes, they should have been moved out of `cl*.el' before the
creation of `cl-lib.el'.  It's not too late to clean things up
now and put them in non-`cl*.el' files where they belong (and
of course remove the `cl-' prefix).  They do not represent
Common Lisp features in any way. 

So call it `letf', not `cl-letf', and move it out of `cl*.el'.
Similarly for anything else that is unrelated to Common Lisp.

> I don't think you've explained the downside of extending CL
> in the cl-namespace. 

It's not about "extending CL in the cl-namespace".  It's about
a misguided, if indirect, attempt to extend Common Lisp, and
giving the mistaken impression that these things are part of
Common Lisp.

It's not about the namespace.  The same bug report applies to
the old `letf' etc. in the old `cl-macs.el' (now called `cl--letf'
in the new `cl-macs.el').  The name `letf' was fine for Emacs.
And it still is.  It just does not belong in `cl*.el'.

> You've articulated an aesthetic point, but I don't see any
> negative technical consequences.

Technical consequences?  It's about how this misleads users -
user consequences.

You've not articulated any criteria for adding a function or
macro to `cl*.el'.

Why not move `while' there as `cl-while'?  Any number of Emacs
functions and macros, could be argued to be "natural extensions
of facilities we got from Common Lisp."  That's too vague to
mean anything helpful.

Just because we got `let', `let*', and `setf' from Common Lisp,
that's no reason that we should add `letf' or `cl-letf' - which
have no counterpart in Common Lisp - to `cl*.el'.

That's what this bug report is about: Just what should be part
of our Common-Lisp emulation package.  The criterion I would
use is this: The only things that belong there are things that
emulate things in Common Lisp.

If Common Lisp has a function or macro `foo' then we can
consider emulating it (under whatever name) and adding it to
the `cl*.el' files.  If not, it belongs elsewhere in Emacs.

What, specifically, are your criteria for inclusion in `cl*.el'?
I was quite specific about mine.  How about you?

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

On 03/08/2015 02:12 PM, Drew Adams wrote:
> It is perfectly fine to extend or redesign Emacs Lisp any way we
> like.  And we can take whatever we want from Common Lisp and do
> whatever we want with it.  We need not try to emulate any given
> Common-Lisp function or macro.  But the things we put in the
> Common-Lisp emulation package should be emulations of Common Lisp
> things, IMO - things designed by the Common-Lisp designers for
> Common Lisp.
> 
> It is not appropriate to add non Common-Lisp things to our
> emulation of Common Lisp.  That's all.

I think cl-lib has long ago stopped being an emulation of common lisp.
Now, it's a CL-*inspired* utility library. I doubt that there's a risk
of real harmful confusion between this library and actual Common Lisp.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Drew Adams]

> > It is perfectly fine to extend or redesign Emacs Lisp any way we
> > like.  And we can take whatever we want from Common Lisp and do
> > whatever we want with it.  We need not try to emulate any given
> > Common-Lisp function or macro.  But the things we put in the
> > Common-Lisp emulation package should be emulations of Common Lisp
> > things, IMO - things designed by the Common-Lisp designers for
> > Common Lisp.
> >
> > It is not appropriate to add non Common-Lisp things to our
> > emulation of Common Lisp.  That's all.
> 
> I think cl-lib has long ago stopped being an emulation of common lisp.

What makes you think so?

Even if that were true, it's not a reason not to clean it up now.

And if it is not to be cleaned up, what criteria (3rd time asking)
do you apply to decide what goes into it and what does not?

> Now, it's a CL-*inspired* utility library. 

What does that even mean?  Inspired how?  What criteria define
what is or is not a "CL-*inspired* utility"?

If ever there was a huge language that touches nearly everything
and nearly every software engineering construct/approach, it's
Common Lisp.  What is not a "CL-*inspired* utility"?

> I doubt that there's a risk of real harmful confusion between
> this library and actual Common Lisp.

Google for `letf' and you will find that just such confusion
has occurred.

And there is no reason for it.  That's the point - it doesn't
have to be this way.

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Stefan Monnier]

FWIW, I'll just mention that I agree with Daniel's assessment.


        Stefan

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Glenn Morris]

Dani Moncayo wrote:

>>> In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
>>>  of 2015-02-27 on LEG570
>>> Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7
>>   ^^^^^^^^^^^^^
>>
>> Dani, what's this "bzr revision" thing about?
>
> I don't know.

For the record, it's a bug in Someone's custom Emacs bug reporting package.

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Drew Adams]

> >>> In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
> >>>  of 2015-02-27 on LEG570
> >>> Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7
> >>  ^^^^^^^^^^^^^
> >>
> >> Dani, what's this "bzr revision" thing about?
> >
> > I don't know.
> 
> For the record, it's a bug in Someone's custom Emacs bug reporting
> package.

Yes, it came fom my library `emacsbug+.el'.
http://www.emacswiki.org/emacs/download/emacsbug%2b.el

It does this:

  (insert "\n\nIn " (emacs-version) "\n")
  (when (and (boundp 'emacs-bzr-version)  (stringp emacs-bzr-version))
    (insert "Bzr revision: " emacs-bzr-version "\n"))

Which is exactly what vanilla Emacs did too, a couple of years
ago.  I just had not updated my library to use the renamed label,
`Repository version:'.  I've done that now, so this scandalous
problem should no longer plague you.

In any case, my code does not define or set `emacs-bzr-version'.

,----
| emacs-bzr-version is a variable defined in `emacsbug+.el'.
| Its value is nil
| 
|   This variable is an alias for `emacs-repository-version'.
|   This variable is obsolete since 24.4;
|   use `emacs-repository-version' instead.
| 
| Documentation:
| String giving the repository revision from which this Emacs was built.
| Value is nil if Emacs was not built from a repository checkout,
| or if we could not determine the revision.
`----

My code uses the old name of this variable because it works,
including across multiple Emacs versions.

Naturally, I proposed the little that `emacsbugs+.el' does to
Emacs Dev for `emacsbug.el'.  Naturally, there was no interest.

What does it do?  It just lets users choose which fields to
include by default in a bug report.  What Emacs does with a
monolithic `report-emacs-bug', this library does with a modular
`report-emacs-bug'.  That's all.  Not a biggee.

User option `ebp-report-emacs-bug-included-fields':

(defcustom ebp-report-emacs-bug-included-fields
  '(version settings major-mode minor-modes recent-input
    recent-messages load-shadows features)
  "Fields to include by default for command `report-emacs-bug'.
The fields are included automatically in the buffer where you edit
your bug report."
  :type '(set
          (const :tag "Emacs version info" version)
          (const :tag "Important settings" settings)
          (const :tag "Major mode"         major-mode)
          (const :tag "Minor modes"        minor-modes)
          (const :tag "Recent input"       recent-input)
          (const :tag "Recent messages"    recent-messages)
          (const :tag "Load-path shadows"  load-shadows)
          (const :tag "Features"           features))
  :group 'emacsbug-plus :group 'convenience)

For my own purposes, I use the value `(version)': report just
the version info, by default.

There are also commands to insert all or any of the fields.
To insert recent input, for example, you can use command
`edp-insert-recent-input'.

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Lars Ingebrigtsen]

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

> FWIW, I'll just mention that I agree with Daniel's assessment.

Seems like most agree that this isn't something to be fixed, and I'm
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Noam Postavsky]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> FWIW, I'll just mention that I agree with Daniel's assessment.
>
> Seems like most agree that this isn't something to be fixed, and I'm
> closing this bug report.

Things have changed since the original discussion though: now that setf
has been moved out of cl-lib, I think cl-letf and cl-callf should go
with it.

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Štěpán Němec]

On Fri, 02 Aug 2019 22:49:19 -0400
Noam Postavsky wrote:

> Things have changed since the original discussion though: now that setf
> has been moved out of cl-lib, I think cl-letf and cl-callf should go
> with it.

As much as I would personally like to get rid of the prefixes, it seems
to me that unless you move _most_ of cl-, you'll only increase the
confusion. Now it's just setf, that's easy to remember, but with more
exceptions one would have to check if a particular form is or isn't
supposed to be used with the prefix all the time (albeit with the help
of the byte compiler).

Considering your proposal in particular, what about shiftf, rotatef?
What makes them different?

-- 
Štěpán

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Lars Ingebrigtsen]

Štěpán Němec <stepnem@gmail.com> writes:

> Considering your proposal in particular, what about shiftf, rotatef?
> What makes them different?

And incf/decf.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Noam Postavsky]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Štěpán Němec <stepnem@gmail.com> writes:
>
>> Considering your proposal in particular, what about shiftf, rotatef?
>> What makes them different?
>
> And incf/decf.

That letf and callf are not defined by Common Lisp.

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Štěpán Němec]

On Sat, 03 Aug 2019 08:58:45 -0400
Noam Postavsky wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Štěpán Němec <stepnem@gmail.com> writes:
>>
>>> Considering your proposal in particular, what about shiftf, rotatef?
>>> What makes them different?
>>
>> And incf/decf.
>
> That letf and callf are not defined by Common Lisp.

Yeah, but setf is... (and as pointed out elsewhere in the thread, letf
and callf really belong naturally with the others).

Anyway, I see that your proposal _is_ in fact limited to these and the
more general cl- problem is beyond this particular bug report, sorry for
the noise.

-- 
Štěpán

bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries

[Stefan Monnier]

> Things have changed since the original discussion though: now that setf
> has been moved out of cl-lib, I think cl-letf and cl-callf should go
> with it.

I'm OK with moving them out of CL, but they should go to gv.el
(i.e. with a `gv-` prefix).  And w.r.t cl-callf, I'd rather replace it
is something slightly different (like the `gv-modify` discussed
recently-ish).


        Stefan