Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

>     * lisp/filenotify.el (top): Require 'cl when compiling.

Please use cl-lib instead.


        Stefan

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>     * lisp/filenotify.el (top): Require 'cl when compiling.
>
> Please use cl-lib instead.

Then I get

In end of data:
filenotify.el:470:1:Warning: the function ‘caadr’ is not known to be defined.

>         Stefan

Best regards, Michael.

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Dmitry Gutov]

On 02/22/2016 10:41 PM, Michael Albinus wrote:

> Then I get
>
> In end of data:
> filenotify.el:470:1:Warning: the function ‘caadr’ is not known to be defined.

Use cl-caadr instead?

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

>> Please use cl-lib instead.

> filenotify.el:470:1:Warning: the function ‘caadr’ is not known to be defined.

Well, of course: all cl-lib definitions use the "cl-" prefix.


        Stefan

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>> Please use cl-lib instead.
>
>> filenotify.el:470:1:Warning: the function ‘caadr’ is not known to be defined.
>
> Well, of course: all cl-lib definitions use the "cl-" prefix.

Hmm, yes. Somehow I'm always unable to remember proper use of cl and
cl-lib :-(

>         Stefan

Thanks, and best regards, Michael.

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

> Hmm, yes. Somehow I'm always unable to remember proper use of cl and
> cl-lib :-(

Easy: stop using `cl' and you'll soon be familiar with proper use of
cl-lib.


        Stefan


PS: While cl-lib is not bundled with Emacs<24.3, the GNU ELPA package by
the same name should work with Emacs≥22 and XEmacs.

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> >> filenotify.el:470:1:Warning: the function ‘caadr’ is not known to be
> >> defined.
> >
> > Well, of course: all cl-lib definitions use the "cl-" prefix.
> 
> Hmm, yes. Somehow I'm always unable to remember proper use of cl and
> cl-lib :-(

It's insane that Emacs now calls these `cl-caddr' etc., instead of
calling them `caddr' etc. like all other Lisps (those that have
them) - including Emacs prior to this renaming.  Hard to believe
this actually went down.

Take a simple, longstanding naming convention designed to be as
succinct and transparent as possible, and coat it in a thick
layer of sticky, gooey mucilage...  ("What were they thinking?")

There is nothing particularly *Common*-Lispy about these functions.
It's not like there was some conflict with other, Emacs-Lisp `caddr'
etc. functions.  What's next, `cl-setq'?  `cl-let'?  `cl-car'?

(No, not a joke - `caddr' is no more Common-Lispy than are `setq',
`let', and `car'.)

I suppose someone could argue that this ugliness might dissuade
people from using these functions.  Hopefully such dissuasion
will work in favor of using context-specific access functions or
macros, or better structuring code.

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Kaushal Modi]

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

On Mon, Feb 22, 2016 at 4:39 PM, Drew Adams <drew.adams@oracle.com> wrote:

> It's insane that Emacs now calls these `cl-caddr' etc., instead of
> calling them `caddr' etc. like all other Lisps (those that have
> them) - including Emacs prior to this renaming.  Hard to believe
> this actually went down.
>

+1

I wholeheartedly agree to that.


--
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 893 bytes --]

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Oleh Krehel]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> On Mon, Feb 22, 2016 at 4:39 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
>
>  It's insane that Emacs now calls these `cl-caddr' etc., instead of
>  calling them `caddr' etc. like all other Lisps (those that have
>  them) - including Emacs prior to this renaming. Hard to believe
>  this actually went down.
>
>
> +1 
>
> I wholeheartedly agree to that.

+1 from me as well. I recall recently Richard proposed that we vote on
some new isearch feature. Should we vote on renaming `cl-caddr' ->
`caddr' as well?

Here's a list of `cl-' stuff that I like to use, which I think wouldn't
bring confusion without a `cl-' prefix: `cl-find-if',
`cl-remove-if-not', `cl-incf', `cl-position-if', `cl-caadr',
`cl-rotatef', `cl-destructuring-bind'.

I realize there are prefix-less aliases for most of these functions.
But I'm not sure how long they're staying. And if they are staying
indefinitely, is there a reason to use `cl-' prefix?  I made a switch to
the prefix some time ago when the unprefixed macros became no longer
syntax-highlighted. But now since recently all macros are syntax
highlighted, no matter where they come from.

    Oleh

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Michael Albinus]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Hmm, yes. Somehow I'm always unable to remember proper use of cl and
>> cl-lib :-(
>
> Easy: stop using `cl' and you'll soon be familiar with proper use of
> cl-lib.

That might be my problem, indeed. Older Tramp versions, backward
compatible, hinder me using this recipe.

>         Stefan

Best regards, Michael.

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> > +1
> >
> > I wholeheartedly agree to that.
> 
> +1 from me as well. I recall recently Richard proposed that we vote on
> some new isearch feature. Should we vote on renaming `cl-caddr' ->
> `caddr' as well?
> 
> Here's a list of `cl-' stuff that I like to use, which I think wouldn't
> bring confusion without a `cl-' prefix: `cl-find-if',
> `cl-remove-if-not', `cl-incf', `cl-position-if', `cl-caadr',
> `cl-rotatef', `cl-destructuring-bind'.
> 
> I realize there are prefix-less aliases for most of these functions.
> But I'm not sure how long they're staying. And if they are staying
> indefinitely, is there a reason to use `cl-' prefix?  I made a switch to
> the prefix some time ago when the unprefixed macros became no longer
> syntax-highlighted. But now since recently all macros are syntax
> highlighted, no matter where they come from.

I understand that we like using library prefixes (I respect that),
hence the use of `cl-'.  But there is plenty in Emacs that is just
plain _Lisp_, and which is not different between Common Lisp and
anything else that Emacs has.  Emacs Lisp has just as much a right
to these Lisp names as any other Lisp.

We don't say `subr-rplacd' just because `rplacd' is defined in `subr.el'.

And we have plenty of functions and macros that are not found in other
Lisps.  Many of those too are in files that are not considered to be
foreign libraries but, like `subr.el', are simply part of the Emacs-Lisp
language.

We don't say `simp-goto-line' just because `goto-line' is defined in
`simple.el'.  And we don't say `diraux-dired-do-chmod' just because
`dired-do-chmod' is defined in `dired-aux.el'.

Why should we act differently when it comes to things like `caddr'?

Regardless of what file they are in, and whether that file is loaded
by default (like `simple.el' and `subr.el') or only on demand (like
`dired-aux.el), I see no good reason for such things to be plastered
over with a `cl-' prefix.

In a way this is a minor, bike-shed point.  And in a way it is
anything but bike-shedding.

To me, it is just common sense to use widespread, longstanding Lisp
names as is, without embellishment.  Unless, that is, there is an
Emacs-Lisp version that already has the unembellished name and is
different.

In the relatively few cases where Emacs Lisp has its own, different
thing that has a widespread Lisp name,  using the `cl-' prefix for
the Common Lisp emulation is appropriate.  And that makes the
difference stand out: This thingy with the `cl-' prefix is different
from the similarly named thingy without that prefix.

Finally, to make things even more muddy, we have recently piled
additional, non-Common Lisp stuff into the `cl-' namespace.  What's
that about?  That just confuses people.

If it's just because such things are in a `cl*.el' file then I think
we're missing the point of such a prefix.  It should be reserved for
Common Lisp emulation, nothing more or less.

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

> That might be my problem, indeed. Older Tramp versions, backward
> compatible, hinder me using this recipe.

But as mentioned, you can use cl-lib in older Emacsen and in XEmacs.


        Stefan

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

> I suppose someone could argue that this ugliness might dissuade
> people from using these functions.

FWIW, I dislike cXXXXr, indeed.  It makes me feel like I'm looking at
assembly code.

> I realize there are prefix-less aliases for most of these functions.

Actually, no.  There isn't.  If you find some, it's only because you
happen to have `cl' loaded.

`cl-destructuring-bind' is often advantageously replaced by pcase-let.

cl-find-if, cl-position-if and cl-remove-if-not use CL-style keywords,
which are poorly (read: inefficiently) supported in Elisp functions, so
if we wanted to add them to Elisp, we'd be better served with something
slightly different which doesn't use keywords.

As for cl-incf, I hesitated to add it to gv.el originally.  In my
experience, it's definitely one of the most often used "cl-*" thingy, so
it's probably one of the best candidates for promoting to "just incf".
cl-cXXXr is relatively rare in comparison (especially if you replace
cl-cad..dr with nth and cl-cd...dr with nthcdr).
As for cl-rotatef I can't remember seeing it used.


        Stefan

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> > I suppose someone could argue that this ugliness might dissuade
> > people from using these functions.
> 
> FWIW, I dislike cXXXXr, indeed.  It makes me feel like I'm looking at
> assembly code.
> 
> > I realize there are prefix-less aliases for most of these functions.
> 
> Actually, no.  There isn't.  If you find some, it's only because you
> happen to have `cl' loaded.

(Not very important, but your quoting above makes it seem that the same
person said both of the things you quoted.  I said the first; Oleh said
the second.)

Wrt cXXXXr, we can all agree, I'm guessing, that context-specific
accessor macros (or functions) that do the same thing are friendlier.
They tell you what the parts you are accessing mean, in context.

But for those lispers who are used to cXXXXr, these functions can
certainly be useful in local contexts (versus introducing a local,
and perhaps meaningless, name).

And yes, they are _good pictures_, showing you just which parts of
a tree are being accessed.  They don't tell you what those structure
parts mean in any given context, but they certainly show you clearly
where the parts are.

Just because such functions exist in Lisp is no reason that any
given Lisp program or programmer has to use them.  But not wanting
to use them is not a good reason to rename them with a `cl-' prefix.

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[John Wiegley]

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

>>>>> Oleh Krehel <ohwoeowho@gmail.com> writes:

>> +1
>> 
>> I wholeheartedly agree to that.

> +1 from me as well. I recall recently Richard proposed that we vote on some
> new isearch feature. Should we vote on renaming `cl-caddr' -> `caddr' as
> well?

> Here's a list of `cl-' stuff that I like to use, which I think wouldn't
> bring confusion without a `cl-' prefix: `cl-find-if', `cl-remove-if-not',
> `cl-incf', `cl-position-if', `cl-caadr', `cl-rotatef',
> `cl-destructuring-bind'.

+100 from me. I deeply dislike the cl- prefix, especially for common things
like incf and loop. It's both excessive, and annoying to program with.

I would like to see prefix-less aliases for many of the functions in cl-lib.
Let's create a module cl-intf that requires cl-lib and provides those aliases;
and then allow cl-intf to be used in core, so long as we ensure that cl-intf
never shadows existing Emacs Lisp functions also in core.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Lars Ingebrigtsen]

John Wiegley <jwiegley@gmail.com> writes:

>> Here's a list of `cl-' stuff that I like to use, which I think wouldn't
>> bring confusion without a `cl-' prefix: `cl-find-if', `cl-remove-if-not',
>> `cl-incf', `cl-position-if', `cl-caadr', `cl-rotatef',
>> `cl-destructuring-bind'.
>
> +100 from me. I deeply dislike the cl- prefix, especially for common things
> like incf and loop.

Me three.

> I would like to see prefix-less aliases for many of the functions in
> cl-lib.  Let's create a module cl-intf that requires cl-lib and
> provides those aliases; and then allow cl-intf to be used in core, so
> long as we ensure that cl-intf never shadows existing Emacs Lisp
> functions also in core.

I kinda worry about the back-and-forthness on this issue, though.  Even
if I really dislike typing and reading stuff like `cl-incf', at least we
had finally arrived at a solution where those functions could be used.
Do we want to rehash this discussion once more?  :-)

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

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

> I would like to see prefix-less aliases for many of the functions in cl-lib.
> Let's create a module cl-intf that requires cl-lib and provides those aliases;
> and then allow cl-intf to be used in core, so long as we ensure that cl-intf
> never shadows existing Emacs Lisp functions also in core.

We have that.  It's called cl.el.


        Stefan

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[John Wiegley]

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

>> I would like to see prefix-less aliases for many of the functions in
>> cl-lib. Let's create a module cl-intf that requires cl-lib and provides
>> those aliases; and then allow cl-intf to be used in core, so long as we
>> ensure that cl-intf never shadows existing Emacs Lisp functions also in
>> core.

> We have that.  It's called cl.el.

That's acceptable to me, so long as its still OK to (eval-when-compile
(require 'cl)) in core modules.  I think this decision started because someone
did that and you asked them to use cl-lib.el.

I have never needed anything more than the macros in cl.el, so if that's the
proposed answer to my concern, I'm fine with that.

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

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

>> We have that.  It's called cl.el.

> That's acceptable to me, so long as its still OK to (eval-when-compile
> (require 'cl)) in core modules.  I think this decision started because
> someone did that and you asked them to use cl-lib.el.

I made an effort to try and eliminate all uses of `cl' (both
compile-time and run-time), with the aim to mark `cl' as obsolete at
some point, and move it to GNU ELPA.

Now, you're the boos, so you don't have to do what I planned.

Still, I think it's silly to keep cl.el other than for backward
compatibility.  Better move the few commonly used thingies out of cl-lib
and remove their "cl-" prefix.  As we've already done over the years
with push/pop/dolist/dotimes/setf/...


        Stefan

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> Better move the few commonly used thingies out of cl-lib
> and remove their "cl-" prefix.  As we've already done over the years
> with push/pop/dolist/dotimes/setf/...

Just remove their prefixes.

Do that to _all_ thingies that do not have a conflict with existing
Emacs-Lisp thingies with the same name.

The question of which of them should be moved out of cl-lib and
into preloaded Emacs files should be based on how much we expect
them to be used.

But it is a different question from what their names should be.
The question about _naming_ should be based on:

1. Whether they do, in fact, correspond to something in Common Lisp.
   If not, remove prefix `cl-' and move them somewhere else.

   File `cl-lib.el' and thingies prefixed `cl-' should correspond to
   Common Lisp thingies (or to internal implementations of Common
   Lisp thingies).

2. Whether the name without `cl-' conflicts with an existing
   Emacs-Lisp name.  If not, remove prefix `cl-' (and leave them
   in `cl-lib').

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[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. ]]]

  > It's insane that Emacs now calls these `cl-caddr' etc., instead of
  > calling them `caddr' etc. like all other Lisps (those that have
  > them) - including Emacs prior to this renaming.

"Renaming" is a misleading description of what happened.
Emacs Lisp never included a caddr function under any name
before among its standard functions.

There was a caddr function in the optional cl package (which I suppose
is still there), and there is now a cl-caddr function in the cl-lib
package.

						     Hard to believe
  > this actually went down.

In 1985 I needed to keep Emacs small.  I could not afford to add
functions such as caddr.

Today, there is no need to keep Emacs so small.  So we may as well add
c...r and c....r to Emacs Lisp.

-- 
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] emacs-25 a9c48d5: Additional fixes for file notification

[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. ]]]

  > Here's a list of `cl-' stuff that I like to use, which I think wouldn't
  > bring confusion without a `cl-' prefix: `cl-find-if',
  > `cl-remove-if-not', `cl-incf', `cl-position-if', `cl-caadr',
  > `cl-rotatef', `cl-destructuring-bind'.

We can consider including some of these functions in standard Emacs
Lisp, but not all the cl-... functions should be included.
Some of the Common Lisp functions have very ugly interfaces.

-- 
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] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

>   > It's insane that Emacs now calls these `cl-caddr' etc., instead of
>   > calling them `caddr' etc. like all other Lisps (those that have
>   > them) - including Emacs prior to this renaming.
> 
> "Renaming" is a misleading description of what happened.
> Emacs Lisp never included a caddr function under any name
> before among its standard functions.
> 
> There was a caddr function in the optional cl package (which I
> suppose is still there),

Precisely.  That `caddr' function is slated (was, at least) to be
removed and thus replaced by the equivalent `cl-caddr' function.
That's what I meant by renaming.  That's what I think is crazy.

> and there is now a cl-caddr function in the cl-lib package.

For now, yes.  Stefan's plan was to obsolete `cl.el'.

>   > Hard to believe this actually went down.
> 
> In 1985 I needed to keep Emacs small.  I could not afford to add
> functions such as caddr.

That's not the "this" that I have a hard time believing went down.
It is the renaming to `cl-' that I find hard to fathom.

> Today, there is no need to keep Emacs so small.  So we may as well add
> c...r and c....r to Emacs Lisp.

Excellent.  Agreed 100%.

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

>   > Here's a list of `cl-' stuff that I like to use, which I think wouldn't
>   > bring confusion without a `cl-' prefix: `cl-find-if',
>   > `cl-remove-if-not', `cl-incf', `cl-position-if', `cl-caadr',
>   > `cl-rotatef', `cl-destructuring-bind'.
> 
> We can consider including some of these functions in standard Emacs
> Lisp, but not all the cl-... functions should be included.
> Some of the Common Lisp functions have very ugly interfaces.

We should move only the functions we think are most useful to
"standard Emacs Lisp".  The rest of the Common Lisp (emulation)
functions should remain in a separate library that is not loaded
by default.

But their functions etc. that correspond to Common Lisp functions
etc. should be renamed to drop the prefix `cl-', unless doing so
would conflict with existing Emacs-Lisp functions etc. that act
differently.

IOW, even when a Common Lisp emulation function is in a separate
library that is not loaded by default, we should drop its prefix
`cl-' unless doing so is problematic.

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

>> Better move the few commonly used thingies out of cl-lib
>> and remove their "cl-" prefix.  As we've already done over the years
>> with push/pop/dolist/dotimes/setf/...

> Just remove their prefixes.

> Do that to _all_ thingies that do not have a conflict with existing
> Emacs-Lisp thingies with the same name.

> The question of which of them should be moved out of cl-lib and into
> preloaded Emacs files should be based on how much we expect them to be used.

I almost agree completely with this, except that I agree with Richard in that
I don't want everything that doesn't conflict moved out of cl-. This would
lead to unnecessary clutter in the global namespace for functions that are
rarely used.

If we want to deprecate cl.el and drop cl- prefixes from a selection of cl-lib
functions, I'm good with that plan. The next step then is determining that
list.

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

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

> If we want to deprecate cl.el and drop cl- prefixes from a selection
> of cl-lib functions, I'm good with that plan. The next step then is
> determining that list.

BTW, for list manipulation functions, most of the cl-* functions should
be deprecated and replaced by seq.el's equivalent, which I find to be
better designed (and to better integrate in Elisp, compared to cl's
excessive reliance on keyword arguments).


        Stefan

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[John Wiegley]

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

> BTW, for list manipulation functions, most of the cl-* functions should be
> deprecated and replaced by seq.el's equivalent, which I find to be better
> designed (and to better integrate in Elisp, compared to cl's excessive
> reliance on keyword arguments).

That sounds fair.  Do we have a cheatsheet for those CLers among us who'd like
to start using seq instead?

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

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Lars Ingebrigtsen]

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

> Still, I think it's silly to keep cl.el other than for backward
> compatibility.  Better move the few commonly used thingies out of cl-lib
> and remove their "cl-" prefix.  As we've already done over the years
> with push/pop/dolist/dotimes/setf/...

I think that's a better idea, too.

How about a shortlist of things we all miss from CL that Emacs Lisp
should have, too?

incf
plusp
Some more c*r variations

union can probably be done with map* functions...
remove/find{-if-not}, too

Uhm...  that was all I was able to think of.  :-)  incf and plusp are
the ones I find myself typing most often.

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

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> > BTW, for list manipulation functions, most of the cl-* functions
> > should be deprecated and replaced by seq.el's equivalent, which
> > I find to be better designed (and to better integrate in Elisp,
> > compared to cl's excessive reliance on keyword arguments).
> 
> That sounds fair.  Do we have a cheatsheet for those CLers among us
> who'd like to start using seq instead?

Yes.  And perhaps the cl functions could be reimplemented in terms
of seq.el, for those who copy some Common Lisp code or who have/reuse
existing code.  (Not I, but there is a lot of Common Lisp out there.)

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

> plusp

First time I see it mentioned in this context.  Why/where do you use it?

The only place where it seems to make sense is in #'plusp (since
otherwise (> x 0) is actually more concise&efficient&precise than (plusp
x) which is my mind suffers from the annoying "is 0 positive?" issue),
but "grep" seems to indicate that's not used anywhere within Emacs (nor
GNU ELPA).


        Stefan

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Lars Ingebrigtsen]

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

> First time I see it mentioned in this context.  Why/where do you use it?

I use it everywhere I want to check whether something is larger than
zero...

> The only place where it seems to make sense is in #'plusp (since
> otherwise (> x 0) is actually more concise&efficient&precise than (plusp
> x) which is my mind suffers from the annoying "is 0 positive?" issue),
> but "grep" seems to indicate that's not used anywhere within Emacs (nor
> GNU ELPA).

That's because I always change it to (if (> foo 0) ..) after first
writing (if (plusp foo) ...).  :-)

Try 

grep --color -nH -e "(>.*\b0\b" `find . -name '*.el'`

instead.

As for concise...  sure, in characters.  But not in meaning.  If I'm
reading code, I'm reading "if that is bigger than... zero!" instead of
immediately getting that it's a check for positivity.

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

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As for concise...  sure, in characters.  But not in meaning.  If I'm
> reading code, I'm reading "if that is bigger than... zero!" instead of
> immediately getting that it's a check for positivity.

(The same logic for `zerop', by the way.)

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

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Clément Pit--Claudel]

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

On 02/23/2016 09:17 PM, Lars Ingebrigtsen wrote:
> Uhm...  that was all I was able to think of.  :-)  incf and plusp are
> the ones I find myself typing most often.

I'd love to see evenp and oddp used more often :)
I think (evenp x) reads much better that (eq (logand x 1) 0). Some examples from the code:

calendar/todo-mode.el:3507:15   : (strlen-odd (eq (logand strlen 1) 1))
calculator.el:1658:13           : ((eq (logand (truncate y) 1) 1)   ; expansion of cl `oddp'
progmodes/ruby-mode.el:1550:6   : (eq (logand (skip-chars-backward "\\") 1)
progmodes/elisp-mode.el:1462:43 : (> index 1) (eq (logand index 1) 1)))
erc/erc.el:6673:9               : (when (eq (logand (length args) 1) 1) ; oddp
play/hanoi.el:273:20            : (if (eq (logand n 1) 1)  ; oddp would require cl at runtime
hexl.el:1011:11                 : (if (eq (logand len 1) 1)

Cheers,
Clément.


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

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

> As for concise...  sure, in characters.  But not in meaning.  If I'm
> reading code, I'm reading "if that is bigger than... zero!" instead of

Just write it (> 0 x) so you don't have to "..." until the punchline.

> immediately getting that it's a check for positivity.

As mentioned, I never remember which kind of "positivity" is used where,
whereas (> 0 x) and (>= 0 x) are 100% unambiguous.

> (The same logic for `zerop', by the way.)

I find (= 0 x) to work just as well, but at least `zerop' doesn't suffer
from plusp's ambiguity, so I'm OK with zerop (tho after having had to
work to make it as efficient as (= 0 x), I started to stay away from
it).


        Stefan

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Lars Ingebrigtsen]

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

>> As for concise...  sure, in characters.  But not in meaning.  If I'm
>> reading code, I'm reading "if that is bigger than... zero!" instead of
>
> Just write it (> 0 x) so you don't have to "..." until the punchline.

Eek!  Yoda comparisons!  I don't even understand what they mean.  I
mean, seriously.  It takes me several seconds to reverse those in my
head and be able to parse them.  And that's common enough among
programmers that one should never use them.

>> immediately getting that it's a check for positivity.
>
> As mentioned, I never remember which kind of "positivity" is used where,
> whereas (> 0 x) and (>= 0 x) are 100% unambiguous.

Well, `plusp' is defined as "bigger than zero"...  Once you've learned
that, it's unambiguous. 

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

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stephen Berman]

On Tue, 23 Feb 2016 23:08:36 -0500 Clément Pit--Claudel <clement.pit@gmail.com> wrote:

> On 02/23/2016 09:17 PM, Lars Ingebrigtsen wrote:
>> Uhm...  that was all I was able to think of.  :-)  incf and plusp are
>> the ones I find myself typing most often.
>
> I'd love to see evenp and oddp used more often :)
> I think (evenp x) reads much better that (eq (logand x 1) 0). Some examples
> from the code:
>
> calendar/todo-mode.el:3507:15   : (strlen-odd (eq (logand strlen 1) 1))

Oops.  Elsewhere in todo-mode I used cl-oddp, but somehow missed this.
I'll change it, probably when I do other code-cleanup (not before 25.1
is released).

Steve Berman

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Dmitry Gutov]

On 02/24/2016 06:09 AM, Stefan Monnier wrote:
>> As for concise...  sure, in characters.  But not in meaning.  If I'm
>> reading code, I'm reading "if that is bigger than... zero!" instead of
>
> Just write it (> 0 x) so you don't have to "..." until the punchline.

I think you've just demonstrated that it's easy to make a mistake in the 
order of >'s arguments.

>> immediately getting that it's a check for positivity.
>
> As mentioned, I never remember which kind of "positivity" is used where,
> whereas (> 0 x) and (>= 0 x) are 100% unambiguous.

Never been a problem for me. "more or equal to zero" is natnump (which 
is already a built-in, though I've never had an occasion to use it 
personally). The divide between positive and natural numbers seems 
pretty clear-cut.

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[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. ]]]

  > It is the renaming to `cl-' that I find hard to fathom.

It wasn't really a renaming.  We always discouraged use of 'cl'.

-- 
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] emacs-25 a9c48d5: Additional fixes for file notification

[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. ]]]

  > But their functions etc. that correspond to Common Lisp functions
  > etc. should be renamed to drop the prefix `cl-',

No way.  That would require in effect reserving all those names
in Emacs Lisp.



-- 
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] emacs-25 a9c48d5: Additional fixes for file notification

[Nicolas Richard]

Lars Ingebrigtsen <larsi@gnus.org> writes:
> Well, `plusp' is defined as "bigger than zero"...  Once you've learned
> that, it's unambiguous. 

FWIW I don't think "bigger than zero" is unambiguous. Maybe that's
because I'm not a native english speaker.

-- 
Nicolas

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Nicolas Richard]

Dmitry Gutov <dgutov@yandex.ru> writes:

>              The divide between positive and natural numbers seems
> pretty clear-cut.

Unfortunately, the terms "natural numbers" is ambiguous enough that the
Wikipedia page about them states very early :
--8<---------------cut here---------------start------------->8---
Some authors begin the natural numbers with 0, corresponding to the
non-negative integers 0, 1, 2, 3, …, whereas others start with 1,
corresponding to the positive integers 1, 2, 3, ….[1][2][3][4] Texts
that exclude zero from the natural numbers sometimes refer to the
natural numbers together with zero as the whole numbers, but in other
writings, that term is used instead for the integers (including
negative integers).
--8<---------------cut here---------------end--------------->8---
(https://en.wikipedia.org/w/index.php?title=Natural_number&oldid=705339412)

Now if you look at the German version, you'll see the first list omits
0, and only afterwards they mention 0 can be included too.
--8<---------------cut here---------------start------------->8---
Die natürlichen Zahlen sind die beim Zählen verwendeten Zahlen 1, 2, 3,
4, 5, 6, 7, 8, 9, 10 usw. Oft wird auch die 0 (Null) zu den natürlichen
Zahlen gerechnet.
--8<---------------cut here---------------end--------------->8---
(https://de.wikipedia.org/w/index.php?title=Nat%C3%BCrliche_Zahl&oldid=151506740)

Anyway, this has only limited implications IMHO : the docstring should
be explicit about what the function does, including which convention of
"positive" or "natural number" it follows (maybe also referencing natnump
from the docstring of plusp).

-- 
Nicolas Richard

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Clément Pit--Claudel]

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

On 02/24/2016 10:18 AM, Nicolas Richard wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> Well, `plusp' is defined as "bigger than zero"...  Once you've learned
>> that, it's unambiguous. 
> 
> FWIW I don't think "bigger than zero" is unambiguous. Maybe that's
> because I'm not a native english speaker.

Same here; not a native speaker either. Greater than 0 doesn't mean the same in French and in English.


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

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> Unfortunately, the terms "natural numbers" is ambiguous enough that
> the Wikipedia page about them states very early :
 
> Now if you look at the German version, you'll see the first list
> omits 0, and only afterwards they mention 0 can be included too.
 
> Anyway, this has only limited implications IMHO : the docstring
> should be explicit about what the function does, including which
> convention of "positive" or "natural number" it follows (maybe also
> referencing natnump from the docstring of plusp).

This seems to have veered off from the topic.  Please consider
taking this to Tangents, or at least starting a separate thread.

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> >> +1  I wholeheartedly agree to that.
> > +1 from me as well.
>
> +100 from me. I deeply dislike the cl- prefix, especially for
> common things like incf and loop. It's both excessive, and
> annoying to program with.
> 
> I would like to see prefix-less aliases for many of the functions
> in cl-lib.  Let's create a module cl-intf that requires cl-lib
> and provides those aliases; and then allow cl-intf to be used
> in core, so long as we ensure that cl-intf never shadows existing
> Emacs Lisp functions also in core.

What about this part of what I wrote.  +100 for that as well?

 Finally, to make things even more muddy, we have recently piled
 additional, non-Common Lisp stuff into the `cl-' namespace.
 What's that about?  That just confuses people.
 
 If it's just because such things are in a `cl*.el' file then I
 think we're missing the point of such a prefix.  It should be 
 reserved for Common Lisp emulation, nothing more or less.

This particular problem was reported as bug #20056, which was
just closed today as "wont-fix".

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[John Wiegley]

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

>>>>> Drew Adams <drew.adams@oracle.com> writes:

>  Finally, to make things even more muddy, we have recently piled
>  additional, non-Common Lisp stuff into the `cl-' namespace.
>  What's that about?  That just confuses people.

> This particular problem was reported as bug #20056, which was
> just closed today as "wont-fix".

Daniel wrote:

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

I agree with Daniel. cl-lib.el is an Emacs Lisp library that makes certain
Common Lisp work-alikes available. It doesn't need to be restricted to *only*
providing functions also in Common Lisp. As long as what's in there has a cl-
prefix, it is in the right place unless it clearly does not belong there. If
you don't like the non-CL functions, don't use them.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> >  Finally, to make things even more muddy, we have recently piled
> >  additional, non-Common Lisp stuff into the `cl-' namespace.
> >  What's that about?  That just confuses people.
> 
> > This particular problem was reported as bug #20056, which was
> > just closed today as "wont-fix".
> 
> Daniel wrote:
> 
> > 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.

Not so long ago, actually.  And unless there is an intention for
it to be for Common Lisp emulation, people will likely continue
to stick any old thing in there that has nothing to do with
Common Lisp.  Unless, of course, there is some other criterion
for inclusion there.  Is there?

> I agree with Daniel. cl-lib.el is an Emacs Lisp library that makes
> certain Common Lisp work-alikes available. It doesn't need to be
> restricted to *only* providing functions also in Common Lisp.

So is there NO criterion for inclusion there?  Anything and
everything belongs there?  If it is no longer for emulating
Common Lisp constructs what is it for now?

> As long as what's in there has a cl- prefix, it is in the
> right place unless it clearly does not belong there.

What defines "clearly does not belong there?  It's apparently
not enough to exclude a function that it have nothing to do
with Common Lisp (or with implementing the CL emulations).

What are the clearly-does-not-belong-there criteria?

> If you don't like the non-CL functions, don't use them.

Dunno where that remark is coming from.  I have no problem with
non-CL Emacs functions.  The question is why give some of them
prefix `cl-' and put them in the CL libraries?

Inclusion there should be based on what?  The question is even
more for future inclusion than it is for moving such functions
out that are already there.

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

>  Finally, to make things even more muddy, we have recently piled
>  additional, non-Common Lisp stuff into the `cl-' namespace.
>  What's that about?  That just confuses people.
[...]
> This particular problem was reported as bug #20056, which was
> just closed today as "wont-fix".

You make it sound like we have many such additions, but I've only heard
of one such so far (namely (cl-)letf).  In the specific case of cl-letf,
I'm not sure where else you'd want to put it (I don't want it as just
unprefixed `letf').


        Stefan

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> >  Finally, to make things even more muddy, we have recently piled
> >  additional, non-Common Lisp stuff into the `cl-' namespace.
> >  What's that about?  That just confuses people.
> [...]
> > This particular problem was reported as bug #20056, which was
> > just closed today as "wont-fix".
> 
> You make it sound like we have many such additions, but I've only
> heard of one such so far (namely (cl-)letf).  In the specific case
> of cl-letf,

Sorry if I did.  I don't know how many there are.  If there is
only one, so much the better - easy to fix.

And again, it is more important for the future than for the past.
No exceptions and a clear policy will help keep the CL libraries
for Common Lisp emulation.

Put differently, I see no good reason why something like `cl-letf'
would be defined in a Common-Lisp emulation library.  `letf' is
simply not Common Lisp.

Oh, but wait -

Browsing through just `cl-macs.el', which is where `cl-letf' is
defined, and searching for just `defmacro', I come across these
non Common-Lisp macros (which are not just implementation building
blocks):

`cl-callf'
`cl-callf2'
`cl-iter-defun'
`cl-flet*'
`cl-letf*'

Moving to `cl-extra' and searching for `defun', I see these:

`cl-prettyprint'   (called a "debugging aid")
`cl-prettyexpand'  (called a "debugging aid")
`cl-describe-type'

Moving to `cl-preloaded.el':

`cl-struct-define'

And there are other `cl*.el' libraries which could be checked.

And it seems that there are internal functions and macros,
which are used only for implementing CL things, which use
prefix `cl-' instead of `cl--'.  For example, `cl-struct-define'.
Should they not be renamed?

So it seems that there at least a few more than just `cl-letf'.

> I'm not sure where else you'd want to put it [`cl-letf']

Doesn't matter to me.  Typically, something as general as that
would go in a library such as `subr.el' or `simple.el', I would
think.  But I'm no expert on the collection of Lisp libraries
we have.

> (I don't want it as just unprefixed `letf').

Why not?

But if there is a good reason for that, fine.  I don't have a
problem with putting it in a library that uses a prefix for
everything - as long as the prefix is not `cl-'.  I really
don't see why `cl-' would not be reserved for emulation of
Common Lisp constructs (and their implementations).

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[John Wiegley]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

> But if there is a good reason for that, fine. I don't have a problem with
> putting it in a library that uses a prefix for everything - as long as the
> prefix is not `cl-'. I really don't see why `cl-' would not be reserved for
> emulation of Common Lisp constructs (and their implementations).

I think you've swayed me by your arguments for consistency, Drew. I tend to
fear being unnecessarily rigid in things, but sloppiness does not serve us
either. If there are functions in cl-*.el that have nothing to do with the
advertised purpose of the cl modules, then maybe it would be better to have
another module for them to live in. Can you please re-open the issue?

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

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> I think you've swayed me by your arguments for consistency, Drew.

Thanks for rethinking about it.

> Can you please re-open the issue?

No; sorry.  I used to be able to reopen bugs, but Glenn decided
I should be prohibited from doing so a few years back and took
away that privilege.

But you can reopen it.  Thx.  And it's not like this is the
most urgent bug to fix.  Having it open need not impede more
important progress.

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Joost Kremers]

On Mon, Feb 29 2016, John Wiegley wrote:
> I agree with Daniel. cl-lib.el is an Emacs Lisp library that makes certain
> Common Lisp work-alikes available. It doesn't need to be restricted to *only*
> providing functions also in Common Lisp.

Perhaps I shouldn't be butting in, being only a modest package
maintainer, but I that doesn't make sense to me. To me, `cl' is so
obviously an abbreviation for Common Lisp that I would automatically
expect any function (macro, etc.) prefixed with `cl-' to be a
Common-Lisp emulation function. The fact that some of them aren't is
quite confusing and makes me wonder by what criterion a function or
macro is included in (or excluded from) cl-lib.



-- 
Joost Kremers
Life has its moments

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

> `cl-callf'
> `cl-callf2'

Don't have an opinion on those two.  They might fit in gv.el.

> `cl-iter-defun'

This one could indeed move to generator.el, tho it currently uses the
internal cl--transform-lambda, so the implementation would need to be
rewoked to avoid having an external package depend on CL's internals.

> `cl-flet*'

This belongs right next to cl-flet, so moving it out of cl-lib would
make no sense.

> `cl-letf*'

This belongs right next to cl-letf.

> `cl-prettyprint'   (called a "debugging aid")
> `cl-prettyexpand'  (called a "debugging aid")
> `cl-describe-type'

These are intimately linked to cl-lib's implementation, AFAIK.

> Moving to `cl-preloaded.el':
> `cl-struct-define'

Same here.  IOW they belong to cl-lib not because they're part of
Common-Lisp, but because they belong to cl-lib's implementation.

> And it seems that there are internal functions and macros,
> which are used only for implementing CL things, which use
> prefix `cl-' instead of `cl--'.  For example, `cl-struct-define'.
> Should they not be renamed?

I don't have a strong opinion on this.  The issue is the following:
cl-struct-define is "used internally by cl-defstruct", but it can't be
changed at will, because it will basically have to be preserved for as
long as Emacs-NN.MM wants to be able to run .elc files generated with
Emacs-24.5.

Those "functions only used in a macro's expansion" have a half-way
"internal" status in this respect, and we sometimes give them
a "prefix-" and sometimes a "prefix--".


        Stefan

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> > `cl-callf'
> > `cl-callf2'
> 
> Don't have an opinion on those two.  They might fit in gv.el.

Good.

> > `cl-iter-defun'
> 
> This one could indeed move to generator.el, tho it currently uses
> the internal cl--transform-lambda, so the implementation would need
> to be rewoked to avoid having an external package depend on CL's
> internals.

Good again.

> > `cl-flet*'
> 
> This belongs right next to cl-flet, so moving it out of cl-lib would
> make no sense.
> 
> > `cl-letf*'
>
> This belongs right next to cl-letf.

It belongs right next to `letf'.  Neither `letf' nor `letf*' are
Common Lisp.  Why should they be in this library and have prefix
`cl-'?  They are Emacs inventions.

> > `cl-prettyprint'   (called a "debugging aid")
> > `cl-prettyexpand'  (called a "debugging aid")
> > `cl-describe-type'
> 
> These are intimately linked to cl-lib's implementation, AFAIK.

1. No, I don't think so, at least not the pretties.  Grepping for
   `cl-prettyprint' shows that it is used only in `cl-prettyexpand'.  
   Grepping for that shows that it used nowhere.

2. But if it were true then they should use prefix `cl--', no?

3. Grepping for `cl-describe-type' shows that it is used only to
   fill `describe-symbol-backends' and to define button type
   `cl-help-type'.  Not Common Lisp at all - just Emacs stuff.

> > Moving to `cl-preloaded.el':
> > `cl-struct-define'
> 
> Same here.  IOW they belong to cl-lib not because they're part of
> Common-Lisp, but because they belong to cl-lib's implementation.

Rename it (there is no "them") using prefix `cl--', if it is really
used only to implement a Common Lisp construct.

> > And it seems that there are internal functions and macros,
> > which are used only for implementing CL things, which use
> > prefix `cl-' instead of `cl--'.  For example, `cl-struct-define'.
> > Should they not be renamed?
> 
> I don't have a strong opinion on this.  The issue is the following:
> cl-struct-define is "used internally by cl-defstruct", but it can't
> be changed at will, because it will basically have to be preserved
> for as long as Emacs-NN.MM wants to be able to run .elc files
> generated with Emacs-24.5.

At the rate things have been changing in the byte-compiler, that
won't be long. ;-)

> Those "functions only used in a macro's expansion" have a half-way
> "internal" status in this respect, and we sometimes give them
> a "prefix-" and sometimes a "prefix--".

How so, "half-way"?  When is it sometimes this and when sometimes
that?

I think Joost expressed the point pretty clearly just now:

  To me, `cl' is so obviously an abbreviation for Common Lisp that
  I would automatically expect any function (macro, etc.) prefixed
  with `cl-' to be a Common-Lisp emulation function. The fact that
  some of them aren't is quite confusing and makes me wonder by what 
  criterion a function or macro is included in (or excluded from)
  cl-lib.

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Stefan Monnier]

>> I don't have a strong opinion on this.  The issue is the following:
>> cl-struct-define is "used internally by cl-defstruct", but it can't
>> be changed at will, because it will basically have to be preserved
>> for as long as Emacs-NN.MM wants to be able to run .elc files
>> generated with Emacs-24.5.
> At the rate things have been changing in the byte-compiler, that
> won't be long. ;-)

Have you had trouble running Emacs-22's .elc files recently?

This said, I'd indeed like to move to an execution model where the .elc
files are "not sufficient" so we can (and do) always fallback on the .el
file in case the .elc is "too old" (or "too new").  This would probably
go along with a move towards an execution model where we automatically
compile .el files.

>   To me, `cl' is so obviously an abbreviation for Common Lisp that
>   I would automatically expect any function (macro, etc.) prefixed
>   with `cl-' to be a Common-Lisp emulation function. The fact that
>   some of them aren't is quite confusing and makes me wonder by what 
>   criterion a function or macro is included in (or excluded from)
>   cl-lib.

In theory the criterion is something along the lies of "either it's
part of CommonLisp, or its implementation makes it belong to cl-lib".
But usually the real criterion is simple: the one who writes and installs
the patch gets to decide.
[ So for example Drew typically doesn't get to decide.  ]



        Stefan

RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[Drew Adams]

> In theory the criterion is something along the lies of "either it's
> part of CommonLisp, or its implementation makes it belong to cl-lib".

That would be reasonable.  It's exactly what I argued for.  Likewise
wrt the prefix.  It excludes things like `letf' that have nothing
to do with CL.

> But usually the real criterion is simple: the one who writes and
> installs the patch gets to decide.

That would be workable, assuming that such decisions are not cast
in concrete when discovered to be mistaken.  In the long run,
theory & practice belong together and correct each other.

What has been missing is the above "theory" as a guideline for such
people.  Bugs happen.  Bugs can be fixed.  The guideline above, like
our coding conventions, can help decide what is a bug.

> [ So for example Drew typically doesn't get to decide. ]

Not a problem.  I haven't tried to decide or asked to decide.

Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification

[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. ]]]

Since we have cl-letf, how about cl-ritgh?
;-).


-- 
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] emacs-25 a9c48d5: Additional fixes for file notification

[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. ]]]

  > Perhaps I shouldn't be butting in, being only a modest package
  > maintainer, but I that doesn't make sense to me. To me, `cl' is so
  > obviously an abbreviation for Common Lisp that I would automatically
  > expect any function (macro, etc.) prefixed with `cl-' to be a
  > Common-Lisp emulation function.

I agree.  Indeed, the only reason we have `cl' and `cl-' is that some
users wanted to add emulation of lots of Common Lisp functions, and I
agreed to it provided they did not go into the main Emacs name space.

When we add Lisp construct for some other reason, rather than putting it
in `cl' or prefixing it with `cl-', we have better options:

* If it is useful enough, give it a short name.

* If it isn't useful enough for a short name, give it a long name.

Perhaps in some special case a non-CL function seems to fit CL
so closely that we could treat it as an honorary import from CL
by putting it in `cl' and `cl-'.  That could be right in some
very special cases.


-- 
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] emacs-25 a9c48d5: Additional fixes for file notification

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> Since we have cl-letf, how about cl-ritgh?
> ;-).

Cl-sure, cl-let's cl-add cl-that. :)

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