* RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-22 22:28 ` Oleh Krehel
@ 2016-02-22 23:15 ` Drew Adams
2016-02-23 1:05 ` John Wiegley
2016-02-23 17:45 ` Richard Stallman
2 siblings, 0 replies; 58+ messages in thread
From: Drew Adams @ 2016-02-22 23:15 UTC (permalink / raw)
To: Oleh Krehel, Kaushal Modi
Cc: Michael Albinus, Stefan Monnier, Emacs developers
> > +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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-22 22:28 ` Oleh Krehel
2016-02-22 23:15 ` Drew Adams
@ 2016-02-23 1:05 ` John Wiegley
2016-02-23 1:58 ` Lars Ingebrigtsen
` (2 more replies)
2016-02-23 17:45 ` Richard Stallman
2 siblings, 3 replies; 58+ messages in thread
From: John Wiegley @ 2016-02-23 1:05 UTC (permalink / raw)
To: Oleh Krehel
Cc: Emacs developers, Michael Albinus, Stefan Monnier, Drew Adams,
Kaushal Modi
[-- 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 --]
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-23 1:05 ` John Wiegley
@ 2016-02-23 1:58 ` Lars Ingebrigtsen
2016-02-23 2:11 ` Stefan Monnier
2016-02-29 6:24 ` Drew Adams
2 siblings, 0 replies; 58+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-23 1:58 UTC (permalink / raw)
To: Emacs developers
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-23 1:05 ` John Wiegley
2016-02-23 1:58 ` Lars Ingebrigtsen
@ 2016-02-23 2:11 ` Stefan Monnier
2016-02-23 16:41 ` John Wiegley
2016-02-29 6:24 ` Drew Adams
2 siblings, 1 reply; 58+ messages in thread
From: Stefan Monnier @ 2016-02-23 2:11 UTC (permalink / raw)
To: Oleh Krehel; +Cc: Emacs developers, Michael Albinus, Drew Adams, Kaushal Modi
> 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
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-23 2:11 ` Stefan Monnier
@ 2016-02-23 16:41 ` John Wiegley
2016-02-23 16:50 ` Stefan Monnier
0 siblings, 1 reply; 58+ messages in thread
From: John Wiegley @ 2016-02-23 16:41 UTC (permalink / raw)
To: Stefan Monnier
Cc: Kaushal Modi, Michael Albinus, Oleh Krehel, Drew Adams,
Emacs developers
>>>>> 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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-23 16:41 ` John Wiegley
@ 2016-02-23 16:50 ` Stefan Monnier
2016-02-23 17:11 ` Drew Adams
2016-02-24 2:17 ` Lars Ingebrigtsen
0 siblings, 2 replies; 58+ messages in thread
From: Stefan Monnier @ 2016-02-23 16:50 UTC (permalink / raw)
To: Oleh Krehel; +Cc: Kaushal Modi, Michael Albinus, Drew Adams, Emacs developers
>> 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
^ permalink raw reply [flat|nested] 58+ messages in thread* RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-23 16:50 ` Stefan Monnier
@ 2016-02-23 17:11 ` Drew Adams
2016-02-23 22:48 ` John Wiegley
2016-02-24 2:17 ` Lars Ingebrigtsen
1 sibling, 1 reply; 58+ messages in thread
From: Drew Adams @ 2016-02-23 17:11 UTC (permalink / raw)
To: Stefan Monnier, Oleh Krehel
Cc: Kaushal Modi, Michael Albinus, Emacs developers
> 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').
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-23 17:11 ` Drew Adams
@ 2016-02-23 22:48 ` John Wiegley
2016-02-24 1:56 ` Stefan Monnier
0 siblings, 1 reply; 58+ messages in thread
From: John Wiegley @ 2016-02-23 22:48 UTC (permalink / raw)
To: Drew Adams
Cc: Emacs developers, Kaushal Modi, Michael Albinus, Stefan Monnier,
Oleh Krehel
>>>>> 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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-23 22:48 ` John Wiegley
@ 2016-02-24 1:56 ` Stefan Monnier
2016-02-24 2:00 ` John Wiegley
0 siblings, 1 reply; 58+ messages in thread
From: Stefan Monnier @ 2016-02-24 1:56 UTC (permalink / raw)
To: Drew Adams; +Cc: Emacs developers, Michael Albinus, Oleh Krehel, Kaushal Modi
> 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
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 1:56 ` Stefan Monnier
@ 2016-02-24 2:00 ` John Wiegley
2016-02-24 2:50 ` Drew Adams
0 siblings, 1 reply; 58+ messages in thread
From: John Wiegley @ 2016-02-24 2:00 UTC (permalink / raw)
To: Stefan Monnier
Cc: Kaushal Modi, Michael Albinus, Oleh Krehel, Drew Adams,
Emacs developers
>>>>> 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
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 2:00 ` John Wiegley
@ 2016-02-24 2:50 ` Drew Adams
0 siblings, 0 replies; 58+ messages in thread
From: Drew Adams @ 2016-02-24 2:50 UTC (permalink / raw)
To: John Wiegley, Stefan Monnier
Cc: Kaushal Modi, Michael Albinus, Oleh Krehel, Emacs developers
> > 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.)
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-23 16:50 ` Stefan Monnier
2016-02-23 17:11 ` Drew Adams
@ 2016-02-24 2:17 ` Lars Ingebrigtsen
2016-02-24 3:32 ` Stefan Monnier
2016-02-24 4:08 ` Clément Pit--Claudel
1 sibling, 2 replies; 58+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-24 2:17 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Emacs developers
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
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 2:17 ` Lars Ingebrigtsen
@ 2016-02-24 3:32 ` Stefan Monnier
2016-02-24 3:52 ` Lars Ingebrigtsen
2016-02-24 4:08 ` Clément Pit--Claudel
1 sibling, 1 reply; 58+ messages in thread
From: Stefan Monnier @ 2016-02-24 3:32 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Emacs developers
> 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
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 3:32 ` Stefan Monnier
@ 2016-02-24 3:52 ` Lars Ingebrigtsen
2016-02-24 3:53 ` Lars Ingebrigtsen
2016-02-24 4:09 ` Stefan Monnier
0 siblings, 2 replies; 58+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-24 3:52 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Emacs developers
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 3:52 ` Lars Ingebrigtsen
@ 2016-02-24 3:53 ` Lars Ingebrigtsen
2016-02-24 4:09 ` Stefan Monnier
1 sibling, 0 replies; 58+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-24 3:53 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Emacs developers
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 3:52 ` Lars Ingebrigtsen
2016-02-24 3:53 ` Lars Ingebrigtsen
@ 2016-02-24 4:09 ` Stefan Monnier
2016-02-24 4:23 ` Lars Ingebrigtsen
2016-02-24 12:21 ` Dmitry Gutov
1 sibling, 2 replies; 58+ messages in thread
From: Stefan Monnier @ 2016-02-24 4:09 UTC (permalink / raw)
To: emacs-devel
> 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
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 4:09 ` Stefan Monnier
@ 2016-02-24 4:23 ` Lars Ingebrigtsen
2016-02-24 15:18 ` Nicolas Richard
2016-02-24 12:21 ` Dmitry Gutov
1 sibling, 1 reply; 58+ messages in thread
From: Lars Ingebrigtsen @ 2016-02-24 4:23 UTC (permalink / raw)
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 4:09 ` Stefan Monnier
2016-02-24 4:23 ` Lars Ingebrigtsen
@ 2016-02-24 12:21 ` Dmitry Gutov
2016-02-24 15:29 ` Nicolas Richard
1 sibling, 1 reply; 58+ messages in thread
From: Dmitry Gutov @ 2016-02-24 12:21 UTC (permalink / raw)
To: Stefan Monnier, emacs-devel
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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 12:21 ` Dmitry Gutov
@ 2016-02-24 15:29 ` Nicolas Richard
2016-02-24 16:51 ` Drew Adams
0 siblings, 1 reply; 58+ messages in thread
From: Nicolas Richard @ 2016-02-24 15:29 UTC (permalink / raw)
To: emacs-devel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 15:29 ` Nicolas Richard
@ 2016-02-24 16:51 ` Drew Adams
0 siblings, 0 replies; 58+ messages in thread
From: Drew Adams @ 2016-02-24 16:51 UTC (permalink / raw)
To: Nicolas Richard, emacs-devel
> 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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 2:17 ` Lars Ingebrigtsen
2016-02-24 3:32 ` Stefan Monnier
@ 2016-02-24 4:08 ` Clément Pit--Claudel
2016-02-24 10:02 ` Stephen Berman
1 sibling, 1 reply; 58+ messages in thread
From: Clément Pit--Claudel @ 2016-02-24 4:08 UTC (permalink / raw)
To: emacs-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-24 4:08 ` Clément Pit--Claudel
@ 2016-02-24 10:02 ` Stephen Berman
0 siblings, 0 replies; 58+ messages in thread
From: Stephen Berman @ 2016-02-24 10:02 UTC (permalink / raw)
To: Clément Pit--Claudel; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-23 1:05 ` John Wiegley
2016-02-23 1:58 ` Lars Ingebrigtsen
2016-02-23 2:11 ` Stefan Monnier
@ 2016-02-29 6:24 ` Drew Adams
2016-02-29 7:06 ` John Wiegley
2016-02-29 17:15 ` Stefan Monnier
2 siblings, 2 replies; 58+ messages in thread
From: Drew Adams @ 2016-02-29 6:24 UTC (permalink / raw)
To: John Wiegley, Oleh Krehel
Cc: Emacs developers, Michael Albinus, Stefan Monnier, Kaushal Modi
> >> +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".
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 6:24 ` Drew Adams
@ 2016-02-29 7:06 ` John Wiegley
2016-02-29 15:41 ` Drew Adams
2016-02-29 19:53 ` Joost Kremers
2016-02-29 17:15 ` Stefan Monnier
1 sibling, 2 replies; 58+ messages in thread
From: John Wiegley @ 2016-02-29 7:06 UTC (permalink / raw)
To: Drew Adams
Cc: Emacs developers, Michael Albinus, Oleh Krehel, Stefan Monnier,
Kaushal Modi
[-- 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 --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 7:06 ` John Wiegley
@ 2016-02-29 15:41 ` Drew Adams
2016-02-29 19:53 ` Joost Kremers
1 sibling, 0 replies; 58+ messages in thread
From: Drew Adams @ 2016-02-29 15:41 UTC (permalink / raw)
To: John Wiegley
Cc: Emacs developers, Michael Albinus, Oleh Krehel, Stefan Monnier,
Kaushal Modi
> > 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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 7:06 ` John Wiegley
2016-02-29 15:41 ` Drew Adams
@ 2016-02-29 19:53 ` Joost Kremers
2016-03-01 16:53 ` Richard Stallman
1 sibling, 1 reply; 58+ messages in thread
From: Joost Kremers @ 2016-02-29 19:53 UTC (permalink / raw)
To: John Wiegley; +Cc: Drew Adams, Emacs developers
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
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 19:53 ` Joost Kremers
@ 2016-03-01 16:53 ` Richard Stallman
0 siblings, 0 replies; 58+ messages in thread
From: Richard Stallman @ 2016-03-01 16:53 UTC (permalink / raw)
To: Joost Kremers; +Cc: johnw, drew.adams, emacs-devel
[[[ 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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 6:24 ` Drew Adams
2016-02-29 7:06 ` John Wiegley
@ 2016-02-29 17:15 ` Stefan Monnier
2016-02-29 18:11 ` Drew Adams
1 sibling, 1 reply; 58+ messages in thread
From: Stefan Monnier @ 2016-02-29 17:15 UTC (permalink / raw)
To: Drew Adams
Cc: Emacs developers, John Wiegley, Michael Albinus, Oleh Krehel,
Kaushal Modi
> 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
^ permalink raw reply [flat|nested] 58+ messages in thread* RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 17:15 ` Stefan Monnier
@ 2016-02-29 18:11 ` Drew Adams
2016-02-29 18:47 ` John Wiegley
` (2 more replies)
0 siblings, 3 replies; 58+ messages in thread
From: Drew Adams @ 2016-02-29 18:11 UTC (permalink / raw)
To: Stefan Monnier
Cc: Emacs developers, John Wiegley, Michael Albinus, Oleh Krehel,
Kaushal Modi
> > 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).
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 18:11 ` Drew Adams
@ 2016-02-29 18:47 ` John Wiegley
2016-02-29 19:28 ` Drew Adams
2016-02-29 20:05 ` Stefan Monnier
2016-03-01 16:53 ` Richard Stallman
2 siblings, 1 reply; 58+ messages in thread
From: John Wiegley @ 2016-02-29 18:47 UTC (permalink / raw)
To: Drew Adams
Cc: Emacs developers, Kaushal Modi, Michael Albinus, Stefan Monnier,
Oleh Krehel
>>>>> 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
^ permalink raw reply [flat|nested] 58+ messages in thread
* RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 18:47 ` John Wiegley
@ 2016-02-29 19:28 ` Drew Adams
0 siblings, 0 replies; 58+ messages in thread
From: Drew Adams @ 2016-02-29 19:28 UTC (permalink / raw)
To: John Wiegley
Cc: Emacs developers, Kaushal Modi, Michael Albinus, Stefan Monnier,
Oleh Krehel
> 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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 18:11 ` Drew Adams
2016-02-29 18:47 ` John Wiegley
@ 2016-02-29 20:05 ` Stefan Monnier
2016-02-29 21:19 ` Drew Adams
2016-03-01 16:53 ` Richard Stallman
2 siblings, 1 reply; 58+ messages in thread
From: Stefan Monnier @ 2016-02-29 20:05 UTC (permalink / raw)
To: Drew Adams
Cc: Emacs developers, John Wiegley, Michael Albinus, Oleh Krehel,
Kaushal Modi
> `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
^ permalink raw reply [flat|nested] 58+ messages in thread* RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 20:05 ` Stefan Monnier
@ 2016-02-29 21:19 ` Drew Adams
2016-02-29 21:57 ` Stefan Monnier
0 siblings, 1 reply; 58+ messages in thread
From: Drew Adams @ 2016-02-29 21:19 UTC (permalink / raw)
To: Stefan Monnier
Cc: Emacs developers, John Wiegley, Michael Albinus, Oleh Krehel,
Kaushal Modi
> > `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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 21:19 ` Drew Adams
@ 2016-02-29 21:57 ` Stefan Monnier
2016-02-29 22:19 ` Drew Adams
0 siblings, 1 reply; 58+ messages in thread
From: Stefan Monnier @ 2016-02-29 21:57 UTC (permalink / raw)
To: Drew Adams
Cc: Emacs developers, John Wiegley, Michael Albinus, Oleh Krehel,
Kaushal Modi
>> 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
^ permalink raw reply [flat|nested] 58+ messages in thread* RE: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 21:57 ` Stefan Monnier
@ 2016-02-29 22:19 ` Drew Adams
0 siblings, 0 replies; 58+ messages in thread
From: Drew Adams @ 2016-02-29 22:19 UTC (permalink / raw)
To: Stefan Monnier
Cc: Emacs developers, John Wiegley, Michael Albinus, Oleh Krehel,
Kaushal Modi
> 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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-29 18:11 ` Drew Adams
2016-02-29 18:47 ` John Wiegley
2016-02-29 20:05 ` Stefan Monnier
@ 2016-03-01 16:53 ` Richard Stallman
2016-03-01 20:09 ` John Wiegley
2 siblings, 1 reply; 58+ messages in thread
From: Richard Stallman @ 2016-03-01 16:53 UTC (permalink / raw)
To: Drew Adams
Cc: johnw, emacs-devel, michael.albinus, ohwoeowho, kaushal.modi,
monnier
[[[ 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.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [Emacs-diffs] emacs-25 a9c48d5: Additional fixes for file notification
2016-02-22 22:28 ` Oleh Krehel
2016-02-22 23:15 ` Drew Adams
2016-02-23 1:05 ` John Wiegley
@ 2016-02-23 17:45 ` Richard Stallman
2 siblings, 0 replies; 58+ messages in thread
From: Richard Stallman @ 2016-02-23 17:45 UTC (permalink / raw)
To: Oleh Krehel
Cc: emacs-devel, michael.albinus, monnier, drew.adams, kaushal.modi
[[[ 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.
^ permalink raw reply [flat|nested] 58+ messages in thread