* Re: Shrinking the C core
@ 2023-08-13 11:20 Gerd Möllmann
2023-08-13 12:52 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Gerd Möllmann @ 2023-08-13 11:20 UTC (permalink / raw)
To: emacs-devel
>> AFAIK, all the Emacs-like implementations mentioned on the
>> web page run on unmodified CL implementations, so you get
>> the speed of that CL implementation.
>
> Uhm, what's an "unmodified CL implementation"?
The implemention as released by the project or vendor.
>
> And what implementations are those, you mean they are not as
> fast as SBCL?
What the Emacs-alikes support varies. I haven't checked recently, but I
know that Lem, for instance, started by only supporting SBCL. Hemlock
is part of CMUCL and wasn't portable, hence Portable Hemlock. There's
also an Emacs-alike that is part of Lispworks' CL implementation
(commencial). And so on. Please consult the project pages.
For some benchmarks on 10 CL implementations, please see
https://www.cliki.net/performance%20benchmarks
BTW, I get DNS errors when sending mail to you via Gmail. Don't know
what's happening.
Reporting-MTA: dns; dataswamp.org
Final-Recipient: rfc822; incal@dataswamp.org
Action: failed
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-13 11:20 Shrinking the C core Gerd Möllmann
@ 2023-08-13 12:52 ` Ihor Radchenko
2023-08-13 15:53 ` [External] : " Drew Adams
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-13 12:52 UTC (permalink / raw)
To: Gerd Möllmann; +Cc: emacs-devel
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> BTW, I get DNS errors when sending mail to you via Gmail. Don't know
> what's happening.
Same for me.
^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [External] : Re: Shrinking the C core
2023-08-13 12:52 ` Ihor Radchenko
@ 2023-08-13 15:53 ` Drew Adams
2023-08-14 2:25 ` Emanuel Berg
0 siblings, 1 reply; 54+ messages in thread
From: Drew Adams @ 2023-08-13 15:53 UTC (permalink / raw)
To: Ihor Radchenko, Gerd Möllmann; +Cc: emacs-devel
> > BTW, I get DNS errors when sending mail to you via Gmail. Don't know
> > what's happening.
>
> Same for me.
Ditto. And it's been pointed out before...
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-08-13 15:53 ` [External] : " Drew Adams
@ 2023-08-14 2:25 ` Emanuel Berg
0 siblings, 0 replies; 54+ messages in thread
From: Emanuel Berg @ 2023-08-14 2:25 UTC (permalink / raw)
To: emacs-devel
Drew Adams wrote:
>>> BTW, I get DNS errors when sending mail to you via Gmail.
>>> Don't know what's happening.
>>
>> Same for me.
>
> Ditto. And it's been pointed out before ...
Seems reasonable as, in this thread alone, three people have
pointed it out.
No, I get your replies here and mails as well for that matter,
but, admittedly, I was fiddling with DNSSEC the other day, and
maybe I br0ke something. Investigating, but have no idea at
the moment what could have caused it.
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
@ 2023-09-13 5:24 Arthur Miller
2023-09-15 8:18 ` Emanuel Berg
0 siblings, 1 reply; 54+ messages in thread
From: Arthur Miller @ 2023-09-13 5:24 UTC (permalink / raw)
To: rms; +Cc: 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. ]]]
>
> > Of course, but nobody suggests it is all-in. `length' is not a keyworded
> > in CL either.
>
>Oops, I thought it was -- but the time when I implemented and used
>Common Lisp was 40 years ago.
>
>I am pretty sure `member' used keyword arguments, and I think that
>getting behavior equivalent to traditional Lisp `member' required
>specifying a keyword argument. I never forgot that, during that
>period, because I got reminded of it almost every day.
>
> > But it is convenient to have keywords in
> > some places, like for example in define-minor-mode or make-process, or
> > even "new" define-keymap.
>
>I would not object to using keyword arguments for functions like that
>-- complex and cumbersome to use, and not used often.
Well, than we pretty much agree 100% about keyword args. 40 years ago I
was playing in the woods, but as I have learned Lisp some barely 2 or 3
years ago, thanks to Emacs Lisp, that is pretty much how I understand
keyword arguments and why they are used, so that is why it felt a bit
strange when you said you don't want them, but I understand now that you
might have felt aversion if they were used everywhere; it certainly is a
PITA in functions with small number of arguments.
Question is also, if Maclisp was developed further, to current day, if
and how it would evolve itself. As time goes buy we discover new idioms,
patterns, have different needs etc. These things changes and new ideas
emerges; it is very much probable that Maclisp itself would look
differently than what it was when CL was conceived. I am sure they
wouldn't have those paires of complementatry functions
(remove-if/remove-if-not) which make for a big part of CL verbosity too.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-13 5:24 Arthur Miller
@ 2023-09-15 8:18 ` Emanuel Berg
2023-09-17 0:46 ` Richard Stallman
0 siblings, 1 reply; 54+ messages in thread
From: Emanuel Berg @ 2023-09-15 8:18 UTC (permalink / raw)
To: emacs-devel
Arthur Miller wrote:
> I am sure they wouldn't have those paires of complementatry
> functions (remove-if/remove-if-not) which make for a big
> part of CL verbosity too.
What is wrong with them?
We have them in Elisp as well, `cl-remove-if' and
`cl-remove-if-not', both in cl-seq.el.
Those functions are pretty useful IMO including use which
includes the keywords, all tho that is optional.
The only thing negative is the documentation, see for example
the docstring of `cl-remove-if-not':
Remove all items not satisfying PREDICATE in SEQ.
This is a non-destructive function; it makes a copy of SEQ
if necessary to avoid corrupting the original SEQ.
Keywords supported: :key :count :start :end :from-end
As you see, it only says what keywords are "supported", not
what they express or how they effect the execution of
the function.
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-15 8:18 ` Emanuel Berg
@ 2023-09-17 0:46 ` Richard Stallman
2023-09-17 4:55 ` Alfred M. Szmidt
` (2 more replies)
0 siblings, 3 replies; 54+ messages in thread
From: Richard Stallman @ 2023-09-17 0:46 UTC (permalink / raw)
To: Emanuel Berg; +Cc: 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. ]]]
> We have them in Elisp as well, `cl-remove-if' and
> `cl-remove-if-not', both in cl-seq.el.
A partial emulation of some Common Lisp functions is present
in the cl-lib library, for emulation purposes. It is not supposed to
be used a lot.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-17 0:46 ` Richard Stallman
@ 2023-09-17 4:55 ` Alfred M. Szmidt
2023-09-17 9:13 ` Emanuel Berg
2023-09-17 5:41 ` Eli Zaretskii
2023-10-20 7:48 ` Arsen Arsenović
2 siblings, 1 reply; 54+ messages in thread
From: Alfred M. Szmidt @ 2023-09-17 4:55 UTC (permalink / raw)
To: rms; +Cc: incal, 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. ]]]
> We have them in Elisp as well, `cl-remove-if' and
> `cl-remove-if-not', both in cl-seq.el.
A partial emulation of some Common Lisp functions is present
in the cl-lib library, for emulation purposes. It is not supposed to
be used a lot.
And if there are functions or features that make sense from Common
Lisp, they can always be added piecemeal. There is no need to make
Emacs Lisp complicated for the sake of compatibility with Common Lisp.
Someone mentioned &optional, and with default values -- that would be
a nice addition to Emacs Lisp.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-17 4:55 ` Alfred M. Szmidt
@ 2023-09-17 9:13 ` Emanuel Berg
2023-09-17 9:54 ` Alfred M. Szmidt
` (2 more replies)
0 siblings, 3 replies; 54+ messages in thread
From: Emanuel Berg @ 2023-09-17 9:13 UTC (permalink / raw)
To: emacs-devel
Alfred M. Szmidt wrote:
>>> We have them in Elisp as well, `cl-remove-if' and
>>> `cl-remove-if-not', both in cl-seq.el.
>>
>> A partial emulation of some Common Lisp functions is
>> present in the cl-lib library, for emulation purposes.
>> It is not supposed to be used a lot.
>
> And if there are functions or features that make sense from
> Common Lisp, they can always be added piecemeal. There is no
> need to make Emacs Lisp complicated for the sake of
> compatibility with Common Lisp.
I don't know why cl-lib was added to GNU Emacs and Emacs Lisp,
maybe it was, as you say, for emulation purposes and for the
sake of compatibility with Common Lisp. But the way it is used
today, as we just heard in 28% of vanilla Emacs files, isn't
because of CL emulation or compatibility purposes, but because
it adds useful features and covers aspects that non-cl-lib
Elisp leaves blank.
For functions like `cl-incf', where there is no corresponding
"incf" [I don't know whatever happened to it or why it was
dropped, or maybe it wasn't ever there before cl-lib?] one
could setup aliases or simply drop the "cl-" prefix (and set
an "cl-incf" alias to the new "incf" as not to break existing
code).
Then, for functions like `cl-defun' and `defun', one would
examine if those could be merged into a new "defun", with the
CL features brought over, e.g. the default &optional argument
value syntax. Here one would again use aliases to cover
the back.
For functions that cannot be merged because they are
inherently different, if such cases exist, one would keep the
"cl-" prefix and the incompatible non-cl-lib Elisp function.
But one could also just leave it the way it is! Since those
prefixes are hardly a big problem. And especially not compared
to all the good features cl-lib brings to our game.
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-17 9:13 ` Emanuel Berg
@ 2023-09-17 9:54 ` Alfred M. Szmidt
2023-09-17 17:38 ` Drew Adams
2023-09-19 10:21 ` Richard Stallman
2 siblings, 0 replies; 54+ messages in thread
From: Alfred M. Szmidt @ 2023-09-17 9:54 UTC (permalink / raw)
To: Emanuel Berg; +Cc: emacs-devel
One should think carefully before thinking of what one should do, or
would do. What one can do is anything... and that is not always the
best thing, these things should be done very carefully and on a case
by case basis. So lets not go crazy.
^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [External] : Re: Shrinking the C core
2023-09-17 9:13 ` Emanuel Berg
2023-09-17 9:54 ` Alfred M. Szmidt
@ 2023-09-17 17:38 ` Drew Adams
2023-09-18 19:38 ` Emanuel Berg
2023-09-19 10:19 ` Richard Stallman
2023-09-19 10:21 ` Richard Stallman
2 siblings, 2 replies; 54+ messages in thread
From: Drew Adams @ 2023-09-17 17:38 UTC (permalink / raw)
To: Emanuel Berg, emacs-devel@gnu.org
> For functions like `cl-incf', where there is no corresponding
> "incf" [I don't know whatever happened to it or why it was
> dropped, or maybe it wasn't ever there before cl-lib?] one
> could setup aliases or simply drop the "cl-" prefix (and set
> an "cl-incf" alias to the new "incf" as not to break existing
> code).
The CL emulation was originally in file `cl.el' and
its helper files, such as `cl-macs.el'. At that time
functions/macros such as `cl-incf' and `cl-case' had
no `cl-' prefix. E.g., Emacs 20:
___
incf is a Lisp macro in `cl'.
(incf PLACE &optional X)
(incf PLACE [X]): increment PLACE by X (1 by default).
PLACE may be a symbol, or any generalized variable allowed by `setf'.
The return value is the incremented value of PLACE.
___
case is a Lisp macro in `cl-macs'.
(case EXPR &rest CLAUSES)
(case EXPR CLAUSES...): evals EXPR, chooses from CLAUSES on that value.
Each clause looks like (KEYLIST BODY...). EXPR is evaluated and compared
against each key in each KEYLIST; the corresponding BODY is evaluated.
If no clause succeeds, case returns nil. A single atom may be used in
place of a KEYLIST of one atom. A KEYLIST of `t' or `otherwise' is
allowed only in the final clause, and matches if no other keys match.
Key values are compared by `eql'.
___
There's no `incf' or `case' in Elisp that would
conflict with the CL-emulation definitions, but
when Someone decided to prefix CL thingies with
`cl-' the decision was to do it wholesale, not
just where there was a collision/conflict with
existing Elisp thingies.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-17 17:38 ` Drew Adams
@ 2023-09-18 19:38 ` Emanuel Berg
2023-09-19 10:19 ` Richard Stallman
1 sibling, 0 replies; 54+ messages in thread
From: Emanuel Berg @ 2023-09-18 19:38 UTC (permalink / raw)
To: emacs-devel
Drew Adams wrote:
>> For functions like `cl-incf', where there is no
>> corresponding "incf" [I don't know whatever happened to it
>> or why it was dropped, or maybe it wasn't ever there before
>> cl-lib?] [...]
>
> The CL emulation was originally in file `cl.el' and its
> helper files, such as `cl-macs.el'. At that time
> functions/macros such as `cl-incf' and `cl-case' had no
> `cl-' prefix. [...]
>
> There's no `incf' or `case' in Elisp that would conflict
> with the CL-emulation definitions, but when Someone decided
> to prefix CL thingies with `cl-' the decision was to do it
> wholesale, not just where there was a collision/conflict
> with existing Elisp thingies.
Ah, I see!
Thanks for explaining.
So I remembered correctly then, that I did use "incf" before
`cl-incf'!
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-17 17:38 ` Drew Adams
2023-09-18 19:38 ` Emanuel Berg
@ 2023-09-19 10:19 ` Richard Stallman
1 sibling, 0 replies; 54+ messages in thread
From: Richard Stallman @ 2023-09-19 10:19 UTC (permalink / raw)
To: Drew Adams; +Cc: incal, 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. ]]]
I think the reason we added `cl-' to all the CL emulations is to
inform people that they are not parts of what Emacs Lisp supports.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-17 9:13 ` Emanuel Berg
2023-09-17 9:54 ` Alfred M. Szmidt
2023-09-17 17:38 ` Drew Adams
@ 2023-09-19 10:21 ` Richard Stallman
2023-09-19 11:21 ` Emanuel Berg
2 siblings, 1 reply; 54+ messages in thread
From: Richard Stallman @ 2023-09-19 10:21 UTC (permalink / raw)
To: Emanuel Berg; +Cc: 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. ]]]
> But the way it is used
> today, as we just heard in 28% of vanilla Emacs files, isn't
> because of CL emulation or compatibility purposes, but because
> it adds useful features and covers aspects that non-cl-lib
> Elisp leaves blank.
I consider this a problem. Such frequent use of the cl facilities --
even though it is just the macros -- adds those cl macros to what
people need to know to understand those files.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-19 10:21 ` Richard Stallman
@ 2023-09-19 11:21 ` Emanuel Berg
2023-09-19 12:39 ` Eli Zaretskii
2023-09-21 20:27 ` Richard Stallman
0 siblings, 2 replies; 54+ messages in thread
From: Emanuel Berg @ 2023-09-19 11:21 UTC (permalink / raw)
To: emacs-devel
Richard Stallman wrote:
>> But the way it is used today, as we just heard in 28% of
>> vanilla Emacs files, isn't because of CL emulation or
>> compatibility purposes, but because it adds useful features
>> and covers aspects that non-cl-lib Elisp leaves blank.
>
> I consider this a problem. Such frequent use of the cl
> facilities -- even though it is just the macros -- adds
> those cl macros to what people need to know to understand
> those files.
Okay, I understand. I must admit I don't really care about
other people at such a fine grained level, but let's think
then ...
I think that non-programmers are a lost cause in this case
anyway and for programmers the complexity increase from
non-cl-lib Elisp to cl-lib is pretty much negligible?
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-19 11:21 ` Emanuel Berg
@ 2023-09-19 12:39 ` Eli Zaretskii
2023-09-21 20:27 ` Richard Stallman
1 sibling, 0 replies; 54+ messages in thread
From: Eli Zaretskii @ 2023-09-19 12:39 UTC (permalink / raw)
To: Emanuel Berg; +Cc: emacs-devel
> From: Emanuel Berg <incal@dataswamp.org>
> Date: Tue, 19 Sep 2023 13:21:59 +0200
>
> for programmers the complexity increase from non-cl-lib Elisp to
> cl-lib is pretty much negligible?
No, it isn't. There's quite a lot of different syntax and semantics
that need to be learned and mastered.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-19 11:21 ` Emanuel Berg
2023-09-19 12:39 ` Eli Zaretskii
@ 2023-09-21 20:27 ` Richard Stallman
1 sibling, 0 replies; 54+ messages in thread
From: Richard Stallman @ 2023-09-21 20:27 UTC (permalink / raw)
To: Emanuel Berg; +Cc: 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. ]]]
> I think that non-programmers are a lost cause in this case
> anyway and for programmers the complexity increase from
> non-cl-lib Elisp to cl-lib is pretty much negligible?
This dichotomy oversimplifies the various levels of skill and
knowledge that people have for Emacs Lisp programming. People's skill
at programming varies across a wide range. Programmers' knowledge of
Emacs Lisp likewise -- there is so much you could learn if you want to
but few have time to learn it all.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-17 0:46 ` Richard Stallman
2023-09-17 4:55 ` Alfred M. Szmidt
@ 2023-09-17 5:41 ` Eli Zaretskii
2023-09-17 8:54 ` Emanuel Berg
2023-10-15 1:53 ` Richard Stallman
2023-10-20 7:48 ` Arsen Arsenović
2 siblings, 2 replies; 54+ messages in thread
From: Eli Zaretskii @ 2023-09-17 5:41 UTC (permalink / raw)
To: rms; +Cc: incal, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sat, 16 Sep 2023 20:46:24 -0400
>
> A partial emulation of some Common Lisp functions is present
> in the cl-lib library, for emulation purposes. It is not supposed to
> be used a lot.
466 out of 1637 Lisp files in Emacs require cl-lib (some of them only
during compilation, i.e. they use only the macros).
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-17 5:41 ` Eli Zaretskii
@ 2023-09-17 8:54 ` Emanuel Berg
2023-09-17 17:29 ` Drew Adams
2023-10-15 1:53 ` Richard Stallman
1 sibling, 1 reply; 54+ messages in thread
From: Emanuel Berg @ 2023-09-17 8:54 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii wrote:
>> A partial emulation of some Common Lisp functions is
>> present in the cl-lib library, for emulation purposes.
>> It is not supposed to be used a lot.
>
> 466 out of 1637 Lisp files in Emacs require cl-lib (some of
> them only during compilation, i.e. they use only the
> macros).
466 out of 1637 files is 28%. It seems that, regardless of any
anti cl-lib sentiments present, the issue has been decided on
the field already.
(format "%d%%" (round (* 100 (/ 466 1637.0)))) ; 28%
The only thing that would have made it more striking is if
Emacs had 1337 files instead.
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-17 5:41 ` Eli Zaretskii
2023-09-17 8:54 ` Emanuel Berg
@ 2023-10-15 1:53 ` Richard Stallman
2023-10-15 2:46 ` Emanuel Berg
2023-10-15 5:54 ` Eli Zaretskii
1 sibling, 2 replies; 54+ messages in thread
From: Richard Stallman @ 2023-10-15 1:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: incal, 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. ]]]
> 466 out of 1637 Lisp files in Emacs require cl-lib (some of them only
> during compilation, i.e. they use only the macros).
If a file uses cl only during compilation (for macros) it is
not much of a problem. How many use it at run time?
I reported one file a few weeks ago that is always (or nearly always)
loaded and uses cl-lib, forcin it to be nearly always loaded too.
That should be fixed.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-10-15 1:53 ` Richard Stallman
@ 2023-10-15 2:46 ` Emanuel Berg
2023-10-15 5:57 ` Eli Zaretskii
2023-10-15 5:54 ` Eli Zaretskii
1 sibling, 1 reply; 54+ messages in thread
From: Emanuel Berg @ 2023-10-15 2:46 UTC (permalink / raw)
To: emacs-devel
Richard Stallman wrote:
>> 466 out of 1637 Lisp files in Emacs require cl-lib (some of
>> them only during compilation, i.e. they use only the
>> macros).
>
> If a file uses cl only during compilation (for macros) it is
> not much of a problem. How many use it at run time?
>
> I reported one file a few weeks ago that is always (or
> nearly always) loaded and uses cl-lib, forcin it to be
> nearly always loaded too. That should be fixed.
But if it is shipped and included with vanilla Emacs, which it
is, how can it be either any more or any less (dis)encouraged
for use than anything else included on the same premises?
If something isn't part of vanilla Emacs one can maybe say
"see if you can do without it, because if you use it, it has
to be brought in externally adding complexity" - perhaps.
But it _is_ included so in terms of technology it is on the
same level as everything else included. Are we gonna have one
big toolbox containing a bunch of tools, but on certain tools
put on little stickers saying "don't use this"?
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-10-15 2:46 ` Emanuel Berg
@ 2023-10-15 5:57 ` Eli Zaretskii
0 siblings, 0 replies; 54+ messages in thread
From: Eli Zaretskii @ 2023-10-15 5:57 UTC (permalink / raw)
To: Emanuel Berg; +Cc: emacs-devel
> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sun, 15 Oct 2023 04:46:45 +0200
>
> Richard Stallman wrote:
>
> >> 466 out of 1637 Lisp files in Emacs require cl-lib (some of
> >> them only during compilation, i.e. they use only the
> >> macros).
> >
> > If a file uses cl only during compilation (for macros) it is
> > not much of a problem. How many use it at run time?
> >
> > I reported one file a few weeks ago that is always (or
> > nearly always) loaded and uses cl-lib, forcin it to be
> > nearly always loaded too. That should be fixed.
>
> But if it is shipped and included with vanilla Emacs, which it
> is, how can it be either any more or any less (dis)encouraged
> for use than anything else included on the same premises?
>
> If something isn't part of vanilla Emacs one can maybe say
> "see if you can do without it, because if you use it, it has
> to be brought in externally adding complexity" - perhaps.
>
> But it _is_ included so in terms of technology it is on the
> same level as everything else included. Are we gonna have one
> big toolbox containing a bunch of tools, but on certain tools
> put on little stickers saying "don't use this"?
This thread is not for casual users of Emacs, it is for active Emacs
developers and maintainers. So please just read it and don't try to
chime in, as that doesn't help.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-10-15 1:53 ` Richard Stallman
2023-10-15 2:46 ` Emanuel Berg
@ 2023-10-15 5:54 ` Eli Zaretskii
2023-10-17 4:51 ` Emanuel Berg
1 sibling, 1 reply; 54+ messages in thread
From: Eli Zaretskii @ 2023-10-15 5:54 UTC (permalink / raw)
To: rms; +Cc: incal, emacs-devel
> From: Richard Stallman <rms@gnu.org>
> Cc: incal@dataswamp.org, emacs-devel@gnu.org
> Date: Sat, 14 Oct 2023 21:53:56 -0400
>
> > 466 out of 1637 Lisp files in Emacs require cl-lib (some of them only
> > during compilation, i.e. they use only the macros).
>
> If a file uses cl only during compilation (for macros) it is
> not much of a problem. How many use it at run time?
226.
> I reported one file a few weeks ago that is always (or nearly always)
> loaded and uses cl-lib, forcin it to be nearly always loaded too.
> That should be fixed.
Which file was that? I cannot reason about its causes to load cl-lib
without knowing the details, which include looking into the file and
considering what it does.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-10-15 5:54 ` Eli Zaretskii
@ 2023-10-17 4:51 ` Emanuel Berg
0 siblings, 0 replies; 54+ messages in thread
From: Emanuel Berg @ 2023-10-17 4:51 UTC (permalink / raw)
To: emacs-devel
Eli Zaretskii wrote:
>>> 466 out of 1637 Lisp files in Emacs require cl-lib (some
>>> of them only during compilation, i.e. they use only the
>>> macros).
>>
>> If a file uses cl only during compilation (for macros) it
>> is not much of a problem. How many use it at run time?
>
> 226.
That means that, out of a total number of 1637 Lisp files in
vanilla Emacs,
466 files, or 28%, require cl-lib overall;
240 files, or 15%, use cl-lib at compile time; and
226 files, or 14%, use cl-lib at run time.
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-17 0:46 ` Richard Stallman
2023-09-17 4:55 ` Alfred M. Szmidt
2023-09-17 5:41 ` Eli Zaretskii
@ 2023-10-20 7:48 ` Arsen Arsenović
2023-10-20 10:08 ` Alfred M. Szmidt
2 siblings, 1 reply; 54+ messages in thread
From: Arsen Arsenović @ 2023-10-20 7:48 UTC (permalink / raw)
To: rms; +Cc: Emanuel Berg, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 774 bytes --]
Hi,
Richard Stallman <rms@gnu.org> writes:
> [[[ 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. ]]]
>
> > We have them in Elisp as well, `cl-remove-if' and
> > `cl-remove-if-not', both in cl-seq.el.
>
> A partial emulation of some Common Lisp functions is present
> in the cl-lib library, for emulation purposes. It is not supposed to
> be used a lot.
Apologies for my ignorance (and late reply), but why not? It hosts some
quite useful functions.
For instance, I'm not aware of an ``flet'' equivalent in Elisp proper.
Thanks in advance, have a lovely day.
--
Arsen Arsenović
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 251 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
@ 2023-08-27 15:14 Arthur Miller
2023-08-28 1:41 ` Po Lu
0 siblings, 1 reply; 54+ messages in thread
From: Arthur Miller @ 2023-08-27 15:14 UTC (permalink / raw)
To: emacs-devel
>> Date: Wed, 9 Aug 2023 21:19:11 -0400
>> From: "Eric S. Raymond" <esr@thyrsus.com>
>> Cc: emacs-devel@gnu.org
>>
>> Po Lu <luangruo@yahoo.com>:
>> > "Eric S. Raymond" <esr@thyrsus.com> writes:
>> >
>> > > When I first worked on Emacs code in the 1980s Lisp was already fast
>> > > enough, and machine speeds have gone up by something like 10^3 since.
>> > > I plain don't believe the "slower" part can be an issue on modern
>> > > hardware, not even on tiny SBCs.
>> >
>> > Can you promise the same, if your changes are not restricted to one or
>> > two functions in fileio.c, but instead pervade throughout C source?
>>
>> Yes, in fact, I can. Because if by some miracle we were able to
>> instantly rewrite the entirety of Emacs in Python (which I'm not
>> advocating, I chose it because it's the slowest of the major modern
>> scripting languages) basic considerations of clocks per second would
>> predict it to run a *dead minimum* of two orders of magnitude faster
>> than the Emacs of, say, 1990.
>>
>> And 1990 Emacs was already way fast enough for the human eye and
>> brain, which can't even register interface lag of less than 0.17
>> seconds (look up the story of Jef Raskin and how he exploited this
>> psychophysical fact in the design of the Canon Cat sometime; it's very
>> instructive). The human auditory system can perceive finer timeslices,
>> down to about 0.02s in skilled musicians, but we're not using elisp
>> for audio signal processing.
>
> This kind of argument is inherently flawed: it's true that today's
> machines are much faster than those in, say, 1990, but Emacs nowadays
> demands much more horsepower from the CPU than it did back then.
> What's more, Emacs is still a single-threaded Lisp machine, although
> in the last 10 years CPU power develops more and more in the direction
> of multiple cores and execution units, with single execution units
> being basically as fast (or as slow) today as they were a decade ago.
>
> And if these theoretical arguments don't convince you, then there are
> facts: the Emacs display engine, for example, was completely rewritten
> since the 1990s, and is significantly more expensive than the old one
> (because it lifts several of the gravest limitations of the old
> redisplay). Similarly with some other core parts and internals.
>
> We are trying to make Lisp programs faster all the time, precisely
> because users do complain about annoying delays and slowness. Various
> optimizations in the byte-compiler and the whole native-compilation
> feature are parts of this effort, and are another evidence that the
> performance concerns are not illusory in Emacs. And we are still not
> there yet: people still do complain from time to time, and not always
> because someone selected a sub-optimal algorithm where better ones
> exist.
>
> The slowdown caused by moving one primitive to Lisp might be
> insignificant, but these slowdowns add up and eventually do show in
> user-experience reports. Rewriting code in Lisp also increases the GC
> pressure, and GC cycles are known as one of the significant causes of
> slow performance in quite a few cases. We are currently tracking the
> GC performance (see the emacs-gc-stats@gnu.org mailing list) for that
> reason, in the hope that we can modify GC and/or its thresholds to
> improve performance.
>
>> If you take away nothing else from this conversation, at least get it
>> through your head that "more Lisp might make Emacs too slow" is a
>> deeply, *deeply* silly idea. It's 2023 and the only ways you can make
>> a user-facing program slow enough for response lag to be noticeable
>> are disk latency on spinning rust, network round-trips, or operations
>> with a superlinear big-O in critical paths. Mere interpretive overhead
>> won't do it.
>
> We found this conclusion to be false in practice, at least in Emacs
> practice.
>
>> > Finally, you haven't addressed the remainder of the reasons I itemized.
>>
>> They were too obvious, describing problems that competent software
>> engineers know how to prevent or hedge against, and you addressed me
>> as though I were a n00b that just fell off a cabbage truck. My
>> earliest contributions to Emacs were done so long ago that they
>> predated the systematic Changelog convention; have you heard the
>> expression "teaching your grandmother to suck eggs"? My patience for
>> that sort of thing is limited.
>
> Please be more patient, and please consider what others here say to be
> mostly in good-faith and based on non-trivial experience. If
> something in what others here say sounds like an offense to your
> intelligence, it is most probably a misunderstanding: for most people
> here English is not their first language, so don't expect them to
> always be able to find the best words to express what they want to
> say.
Very interesting discussion going on for a long time.
I think you are all correct, and wrong to an extent, but I believe that
nobody has touched the fundamental issue: emacs design is flawed beyond
repair for todays machines. Not necessarily in pejorative meaning, but
to repair Emacs you would have to significantly rework internals, to the
point of entire design rewrite. Emacs is a child of its time (like
everything else). It was designed for the time of single-core slow
machine, and its design makes sense in that perspective. However, for
todays multicore machines, the fact that a lisp machine is slapped on
top of an existing text editor (Gosslings I guess), and everything is
shared via global state, can't be addressed in any other way but to
rewrite Emacs core from ground up. No amount of patch slapping onto the
current design can compensate for the lack of appropriate desing.
RMS has one abandoned TECO design to adapt Emacs to new times; perhaps
the time has come to do it again.
Sure, you can rework the C core completely, and implement better GC,
threads, and what not, but it seems signficant less work to re-implement
Emacs in a language that already has proper infrastructure in the place,
such as Common Lisp on ccl/sbcl, instead of duplicating all the work.
I understand machines of the time were to slow for a language as big as
Common Lisp when Emacs switched from TECO to C, but today the situation
is different. I am quite sure that sbcl would offer enough speed for a
text editor implementation. As you all have already noticed, speed is
limited by a human factor anyway.
We also see many projects that are duplicating Emacs idea, and with all
right; the ideas of Emacs are indeed sound and very good. But it is a
shame to abandon 40 years of development and the community that Emacs
has, something other projects can't compete with. Emacs Lisp is de
facto, *the* best documented Lisp out there, and Emacs is one of the
best documented open source projects available, kudos for that to
everyone involved. It would be a pittiful waste to just throw away all
that documentation and work done, as well as the vivid community that
Emacs has. In my personal opinon, those are *the* qualities of Emacs as
a project.
I personally believe that Emacs as a project would benefit of complete
core rewrite, as well as unifying the extension and the implementation
language for several reasons. Yes, it is a lot of work, but even
rewriting C core to adapt Emacs to modern machines is a lot of work in
itself, if it is even possible. You can either let it be, and slowly but
surely see Emacs usage decline, or you can rewrite Emacs core (again) to
better suit modern multicore machines.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-27 15:14 Arthur Miller
@ 2023-08-28 1:41 ` Po Lu
2023-08-28 4:53 ` Arthur Miller
0 siblings, 1 reply; 54+ messages in thread
From: Po Lu @ 2023-08-28 1:41 UTC (permalink / raw)
To: Arthur Miller; +Cc: emacs-devel
Arthur Miller <arthur.miller@live.com> writes:
> Very interesting discussion going on for a long time.
>
> I think you are all correct, and wrong to an extent, but I believe that
> nobody has touched the fundamental issue: emacs design is flawed beyond
> repair for todays machines. Not necessarily in pejorative meaning, but
> to repair Emacs you would have to significantly rework internals, to the
> point of entire design rewrite. Emacs is a child of its time (like
> everything else). It was designed for the time of single-core slow
> machine, and its design makes sense in that perspective. However, for
> todays multicore machines, the fact that a lisp machine is slapped on
> top of an existing text editor (Gosslings I guess), and everything is
> shared via global state, can't be addressed in any other way but to
> rewrite Emacs core from ground up. No amount of patch slapping onto the
> current design can compensate for the lack of appropriate desing.
Unix was designed for 16-bit uniprocessor machines, where the only form
of ``interlocking'' was:
int x = spltty ();
splx (x);
But today, both free BSD Unix and proprietary Unix scale to SMPs with
hundereds of processors, exploiting intricate interlocking around
individual kernel data structures. The perfect antithesis to your
standpoint...
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-28 1:41 ` Po Lu
@ 2023-08-28 4:53 ` Arthur Miller
2023-08-28 5:36 ` Po Lu
0 siblings, 1 reply; 54+ messages in thread
From: Arthur Miller @ 2023-08-28 4:53 UTC (permalink / raw)
To: Po Lu; +Cc: emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Arthur Miller <arthur.miller@live.com> writes:
>
>> Very interesting discussion going on for a long time.
>>
>> I think you are all correct, and wrong to an extent, but I believe that
>> nobody has touched the fundamental issue: emacs design is flawed beyond
>> repair for todays machines. Not necessarily in pejorative meaning, but
>> to repair Emacs you would have to significantly rework internals, to the
>> point of entire design rewrite. Emacs is a child of its time (like
>> everything else). It was designed for the time of single-core slow
>> machine, and its design makes sense in that perspective. However, for
>> todays multicore machines, the fact that a lisp machine is slapped on
>> top of an existing text editor (Gosslings I guess), and everything is
>> shared via global state, can't be addressed in any other way but to
>> rewrite Emacs core from ground up. No amount of patch slapping onto the
>> current design can compensate for the lack of appropriate desing.
>
> Unix was designed for 16-bit uniprocessor machines, where the only form
> of ``interlocking'' was:
>
> int x = spltty ();
> splx (x);
>
> But today, both free BSD Unix and proprietary Unix scale to SMPs with
> hundereds of processors, exploiting intricate interlocking around
> individual kernel data structures. The perfect antithesis to your
> standpoint...
In which way is it "the perfect antithesis" to my standpoint, and what
is my standpoint?
If you wrote:
"where the only form of ``interlocking'' **is**",
than it would certainly be a "perfect anthithesis", but since you are
using the term *was* it means it *is no more*, a past tense, something
that has changed, and change is what I have suggested.
I think you are missunderstanding what I am saying: I am saying that
design needs to be changed; and the other thing is that I am suggesting
to rewrite the core API in CL instead of C, since you will get all those
things that constitute the Lisp Machine out for free; a better garbage
collector, a better threading, and better Lisp that are people are often
asking for. Of course you can implement all that stuff in C as well, it
just that it means redoing work that other people has done elsewhere.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-28 4:53 ` Arthur Miller
@ 2023-08-28 5:36 ` Po Lu
2023-08-28 6:55 ` Arthur Miller
0 siblings, 1 reply; 54+ messages in thread
From: Po Lu @ 2023-08-28 5:36 UTC (permalink / raw)
To: Arthur Miller; +Cc: emacs-devel
Arthur Miller <arthur.miller@live.com> writes:
> In which way is it "the perfect antithesis" to my standpoint, and what
> is my standpoint?
That Emacs must be rewritten from the drawing board to leverage
multiprocessor operation.
> If you wrote:
>
> "where the only form of ``interlocking'' **is**",
>
> than it would certainly be a "perfect anthithesis", but since you are
> using the term *was* it means it *is no more*, a past tense, something
> that has changed, and change is what I have suggested.
Multiple organizations took Unix and independently transformed it into
what it is today: CMU, Novell, Sun, and of course the many volunteers
who orchestrate the development of the free BSD systems.
What fundamental issues (aside from manpower and time, of course) impede
Emacs from undergoing the same transformation? The Unix experience
indicates that this is well-trodden ground.
> I think you are missunderstanding what I am saying: I am saying that
> design needs to be changed; and the other thing is that I am suggesting
> to rewrite the core API in CL instead of C, since you will get all those
> things that constitute the Lisp Machine out for free; a better garbage
> collector, a better threading, and better Lisp that are people are often
> asking for. Of course you can implement all that stuff in C as well, it
> just that it means redoing work that other people has done elsewhere.
Last I checked, none of the popular Common Lisp systems supported MS-DOS
or ran satisfactorily on Android, nor was Common Lisp an especially well
known language. There is a reason Emacs is written in C, and why its
present design has endured for so long: it is portable, it is reasonably
fast, and it is a subject familiar to all programmers.
Other Lisp systems aren't panaceas either: rewritten in Common Lisp or
not, the present Emacs design will still require interlocking to operate
safely in a multiprocessor environment. Ergo, such a rewrite will only
compound the effort needed to produce a hypothetical ``Lockmacs'' (so to
speak) with the additional pains required to rewrite Emacs in a new
language, and one very few of the present maintainers are well versed in
at that.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-28 5:36 ` Po Lu
@ 2023-08-28 6:55 ` Arthur Miller
2023-08-28 7:31 ` Po Lu
0 siblings, 1 reply; 54+ messages in thread
From: Arthur Miller @ 2023-08-28 6:55 UTC (permalink / raw)
To: Po Lu; +Cc: emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Arthur Miller <arthur.miller@live.com> writes:
>
>> In which way is it "the perfect antithesis" to my standpoint, and what
>> is my standpoint?
>
> That Emacs must be rewritten from the drawing board to leverage
> multiprocessor operation.
I think you have missunderstand what I mean; I can try make it clear
that I mean parts that considers Emacs core, shared state and so on.
>> If you wrote:
>>
>> "where the only form of ``interlocking'' **is**",
>>
>> than it would certainly be a "perfect anthithesis", but since you are
>> using the term *was* it means it *is no more*, a past tense, something
>> that has changed, and change is what I have suggested.
>
> Multiple organizations took Unix and independently transformed it into
> what it is today: CMU, Novell, Sun, and of course the many volunteers
> who orchestrate the development of the free BSD systems.
You are missing the point: I wasn't talking about *who* changed the
Unix; the point here is that it got *changed*.
> What fundamental issues (aside from manpower and time, of course) impede
> Emacs from undergoing the same transformation? The Unix experience
> indicates that this is well-trodden ground.
None. And nobody has suggested that such issues exists either, it is your
construction. On contrary, I am saying that Emacs should undergo such
transformation :).
>> I think you are missunderstanding what I am saying: I am saying that
>> design needs to be changed; and the other thing is that I am suggesting
>> to rewrite the core API in CL instead of C, since you will get all those
>> things that constitute the Lisp Machine out for free; a better garbage
>> collector, a better threading, and better Lisp that are people are often
>> asking for. Of course you can implement all that stuff in C as well, it
>> just that it means redoing work that other people has done elsewhere.
>
> Last I checked, none of the popular Common Lisp systems supported MS-DOS
True. MS-DOS and Windows 95 would have to go away. Perhaps some other
popular OS from 1980s-1990s?
> or ran satisfactorily on Android, nor was Common Lisp an especially well
> known language. There is a reason Emacs is written in C, and why its
> present design has endured for so long: it is portable, it is reasonably
> fast, and it is a subject familiar to all programmers.
Well yes, C is portable and fast, nobody denies that. So are some CL
compilers.
> Other Lisp systems aren't panaceas either: rewritten in Common Lisp or
Nobody said it is "panaceas". But sbcl would provide a better lisp
machine, in terms of garbagecollector, threading etc; something you will
have to develop for Emacs eventually. You heard that one about a guy
with name Isaac Newton and standing on shoulders of others? :)
> not, the present Emacs design will still require interlocking to operate
> safely in a multiprocessor environment. Ergo, such a rewrite will only
> compound the effort needed to produce a hypothetical ``Lockmacs'' (so to
Just reimplementing the C core would not, because you wouldn't use
multiple threads. But if you would like to thread Emacs command loop or
internals itself, than you would have to reimplement it that way of
course. Think of Java Swing; at least 20 years ago when I war
programming Java, it was not thread safe, but worker threads were OK.
> speak) with the additional pains required to rewrite Emacs in a new
> language, and one very few of the present maintainers are well versed in
> at that.
I am sure present maintainers are well versed with CL, just not very
interested to rewrite Emacs in CL; and I wouldn't expected them to be
either :-).
Observe that I am presenting some food for thought; I don't expect Emacs
devs to jump and say "Yes! What a great idea!". But I wouldn't be
suprised if at least some of them have had the idea in their mind at
some point in time.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-28 6:55 ` Arthur Miller
@ 2023-08-28 7:31 ` Po Lu
2023-08-28 14:08 ` Arthur Miller
0 siblings, 1 reply; 54+ messages in thread
From: Po Lu @ 2023-08-28 7:31 UTC (permalink / raw)
To: Arthur Miller; +Cc: emacs-devel
Arthur Miller <arthur.miller@live.com> writes:
> I think you have missunderstand what I mean; I can try make it clear
> that I mean parts that considers Emacs core, shared state and so on.
That's what I was referring to, yes.
> You are missing the point: I wasn't talking about *who* changed the
> Unix; the point here is that it got *changed*.
My point is, Unix has demonstrated many times over that programs written
in C can be interlocked, and doing so is more productive than a rewrite.
> None. And nobody has suggested that such issues exists either, it is your
> construction. On contrary, I am saying that Emacs should undergo such
> transformation :).
That contradicts your assertions below, where you propose returning to
the drawing board to produce an Emacs written in Common Lisp. Curiously
enough, I can't locate any precedent for large and complex Common Lisp
programs being modified for multi-processor operation.
> True. MS-DOS and Windows 95 would have to go away. Perhaps some other
> popular OS from 1980s-1990s?
They wouldn't have to go away if Emacs remains written in C.
> Well yes, C is portable and fast, nobody denies that. So are some CL
> compilers.
Which Common Lisp compiler is capable of linking with Java code through
the JNI? (ABCL doesn't work, as the Android JVM can't interpret the
bytecode it generates.)
> Nobody said it is "panaceas". But sbcl would provide a better lisp
> machine, in terms of garbagecollector, threading etc; something you will
> have to develop for Emacs eventually. You heard that one about a guy
> with name Isaac Newton and standing on shoulders of others? :)
SBCL only supports kernel-based threads on a handful of systems, and its
garbage collection strategies vary between machine types. I'm sure we
would be capable of supporting more while remaining portable, and Common
Lisp leaves much to be desired as a pair of shoulders to stand on.
> Just reimplementing the C core would not, because you wouldn't use
> multiple threads. But if you would like to thread Emacs command loop or
> internals itself, than you would have to reimplement it that way of
> course. Think of Java Swing; at least 20 years ago when I war
> programming Java, it was not thread safe, but worker threads were OK.
You're okay with Emacs crashing if threads, wielded incorrectly, trample
over internal state? If so, the global lock could be lifted from Emacs
Lisp in under a week.
Instead of denigrating the C language, Emacs's C core, and so many other
components critical to Emacs that have been subject to unjustified
invective in recent times, why not direct your attention to a more
productive task, such as identifying the complex interdependencies
between different pieces of Emacs's global state to establish a detailed
plan for their interlocking? For this task, the most important tool is
a control-flow visualizer such as cflow, and an ample supply of paper.
> I am sure present maintainers are well versed with CL, just not very
> interested to rewrite Emacs in CL; and I wouldn't expected them to be
> either :-).
Two data points: I'm not an adept Common Lisp programmer, nor is Eli.
I'm not even an Emacs Lisp programmer by vocation.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-28 7:31 ` Po Lu
@ 2023-08-28 14:08 ` Arthur Miller
2023-08-31 2:07 ` Richard Stallman
0 siblings, 1 reply; 54+ messages in thread
From: Arthur Miller @ 2023-08-28 14:08 UTC (permalink / raw)
To: Po Lu; +Cc: emacs-devel
Po Lu <luangruo@yahoo.com> writes:
> Arthur Miller <arthur.miller@live.com> writes:
>
>> I think you have missunderstand what I mean; I can try make it clear
>> that I mean parts that considers Emacs core, shared state and so on.
>
> That's what I was referring to, yes.
>
>> You are missing the point: I wasn't talking about *who* changed the
>> Unix; the point here is that it got *changed*.
>
> My point is, Unix has demonstrated many times over that programs written
> in C can be interlocked, and doing so is more productive than a rewrite.
Unix which? Unix is not a single program; it is a family of operating
systems, and I am quite sure nobody runs the same kernel they did back in
1970. I don't know what you are talking about you have
"demonestrated". You said yourself *was* and not *is* which suggest that
those kernels are rewritten in order to support those C programs that
can be interlocked. Again you are constructing yourself things here: I
haven't said it is impossible to write mulththreaded C application that
can use locking.
There are many applicaitons that have been redesigned. Emacs has been
redesigned since its first incarnations as TECO editor if I have
understand the history. For the very last time: I haven't
said Emacs *can not be redesigned*, on the contrary, I said Emacs
*should be* redesigned. Emacs core so to say. You are fighting against
things I haven't said; I don't know why, if it is lack of English skill,
or something else, but we are talking constantly beside each other.
> in C can be interlocked, and doing so is more productive than a rewrite.
Are you saying that a non-multihtreaded program written in C can
suddenly become multithreaded without being re-written to support
threading? Nevermind, you are totally, on purpose or lack of
understanding, missing the point: you have to rewrite stuff to make it
multithreaded regardless of the language if you intention is to have
Emacs core multithreaded. Supporting multithreading is not same as
having entire Emacs internals be multithreaded.
>> None. And nobody has suggested that such issues exists either, it is your
>> construction. On contrary, I am saying that Emacs should undergo such
>> transformation :).
>
> That contradicts your assertions below, where you propose returning to
No, it does not because you have missunderstood that I mean something else.
> the drawing board to produce an Emacs written in Common Lisp. Curiously
I propose porting core API to Common Lisp because that would save you
implementing all those things that you need to make Emacs
multithreaded, better GC etc, because it is not a trivial task.
Of course you can re-write all that stuff in C too, nobody is denying
that it is possible. I am saying there is no need to reduplicate the
work, and there are other benefits of having Emacs in Common Lisp.
> enough, I can't locate any precedent for large and complex Common Lisp
> programs being modified for multi-processor operation.
Look harder.
>> True. MS-DOS and Windows 95 would have to go away. Perhaps some other
>> popular OS from 1980s-1990s?
>
> They wouldn't have to go away if Emacs remains written in C.
Tough argument indeed.
It is certainly very importnat to keep the development back to
support two ancient non-free OS:s.
>> Well yes, C is portable and fast, nobody denies that. So are some CL
>> compilers.
>
> Which Common Lisp compiler is capable of linking with Java code through
> the JNI? (ABCL doesn't work, as the Android JVM can't interpret the
> bytecode it generates.)
I don't know what you are trying to say; that sound like very uninformed
statement based on missunderstanding. Calling Java via native API and
generating bytecode that runs Lisp on top of Java as ABCL does are two
completely different and separate things. I am quite sure Emacs does not
generate Java byte code. But I don't see how is it even relevant, I
haven't suggested to run Emacs on JVM. Perhaps it is possible who know,
but I have suggested to use sbcl which is a native compiler specialized
for compiling Lisp (and runs on Android as well).
>> Nobody said it is "panaceas". But sbcl would provide a better lisp
>> machine, in terms of garbagecollector, threading etc; something you will
>> have to develop for Emacs eventually. You heard that one about a guy
>> with name Isaac Newton and standing on shoulders of others? :)
>
> SBCL only supports kernel-based threads on a handful of systems, and its
"only" ? :-) I can asure you that Lispers have access to both kernel and
user space threads. Search on Bordeaux threads.
> garbage collection strategies vary between machine types. I'm sure we
Does it?
> would be capable of supporting more while remaining portable, and Common
> Lisp leaves much to be desired as a pair of shoulders to stand on.
I am also sure everything is possible, it is software, as a wise old
grey head once said. It is just how much effort and resource you are
pouring into it. SBCL runs on basically all important platforms on which
Emacs runs, minus as mentioned DOS and Windows95; I don't know if there is
some other. But it is not the point. The point is: there is another
community working on the same problems you have or wish to solve. And
they have come far away than you. You could re-use their work, and if
you miss somethign add those missing parts so everyone would benefit, or
you can live in an isolated island and do everything yourself.
>> Just reimplementing the C core would not, because you wouldn't use
>> multiple threads. But if you would like to thread Emacs command loop or
>> internals itself, than you would have to reimplement it that way of
>> course. Think of Java Swing; at least 20 years ago when I war
>> programming Java, it was not thread safe, but worker threads were OK.
>
> You're okay with Emacs crashing if threads, wielded incorrectly, trample
> over internal state? If so, the global lock could be lifted from Emacs
> Lisp in under a week.
I am telling you that sbcl/ccl has already solved those problems you
have to solve in order to have multithreading without having to lift
your lock.
> Instead of denigrating the C language, Emacs's C core, and so many other
> components critical to Emacs that have been subject to unjustified
> invective in recent times, why not direct your attention to a more
I don't think I understand how I "denigrate the C language" and what
"unjustify invective" in this case is, but I don't think it
matters. Once you also said I should be forbidden to talk about Emacs.
> direct your attention to a more
> productive task, such as identifying the complex interdependencies
> between different pieces of Emacs's global state to establish a detailed
> plan for their interlocking? For this task, the most important tool is
> a control-flow visualizer such as cflow, and an ample supply of paper.
Can we save nature and our selves?
>> I am sure present maintainers are well versed with CL, just not very
>> interested to rewrite Emacs in CL; and I wouldn't expected them to be
>> either :-).
>
> Two data points: I'm not an adept Common Lisp programmer, nor is Eli.
> I'm not even an Emacs Lisp programmer by vocation.
Nor are you sole Emacs devs, aren't you? I don't think calling names is
appropriate, so I want, but I can come up with at least four people who
work on Emacs and who are experienced Lispers. How active they are in
development recently I don't know, I don't follow the list every day as
I am used to, but I certainly haven't targeted Eli nor you with that one.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-28 14:08 ` Arthur Miller
@ 2023-08-31 2:07 ` Richard Stallman
2023-09-06 0:58 ` Richard Stallman
0 siblings, 1 reply; 54+ messages in thread
From: Richard Stallman @ 2023-08-31 2:07 UTC (permalink / raw)
To: Arthur Miller; +Cc: luangruo, 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. ]]]
Would you please stop arguing for rewriting Emacs in Common Lisp? It
is a non-starter.
It would be an enormouse job -- including rewriting the Emacs Lisp
Referance Manual. We can't be sure how much the benefit would be,
because Common Lisp has some drawbacks too. But we know the cost is
prohibitive.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-31 2:07 ` Richard Stallman
@ 2023-09-06 0:58 ` Richard Stallman
2023-09-06 5:04 ` Arthur Miller
0 siblings, 1 reply; 54+ messages in thread
From: Richard Stallman @ 2023-09-06 0:58 UTC (permalink / raw)
To: rms; +Cc: arthur.miller, luangruo, 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. ]]]
> Would you please stop arguing for rewriting Emacs in Common Lisp? It
> is a non-starter.
> It would be an enormouse job -- including rewriting the Emacs Lisp
> Referance Manual.
Also, there are aspects of Common Lisp which i rejected as clumsy and
best avoided. All those keyword arguments! I intentionally excluded
tham from Emacs and I am not going to let them in.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-09-06 0:58 ` Richard Stallman
@ 2023-09-06 5:04 ` Arthur Miller
2023-09-06 11:29 ` Alan Mackenzie
0 siblings, 1 reply; 54+ messages in thread
From: Arthur Miller @ 2023-09-06 5:04 UTC (permalink / raw)
To: Richard Stallman; +Cc: luangruo, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ 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. ]]]
>
> > Would you please stop arguing for rewriting Emacs in Common Lisp? It
> > is a non-starter.
>
> > It would be an enormouse job -- including rewriting the Emacs Lisp
> > Referance Manual.
>
> Also, there are aspects of Common Lisp which i rejected as clumsy and
With all respect to you, but sound to me like an emotional argument, not
a rational one.
I don't know why you reject them as clumsy, but why does it matter to us
if a tool includes features we don't use? I don't know if I understand
it correctly, but CL was made so other Lisps can be abstracted on top of
it; so we use those features to abstract stuff on top of those lengthy
verbose functions? In other words we can hide those keyword params
behind elispy abstractions if we don't like them?
> best avoided.
Why are they best avoided? Is there some technical reason or is it
psychological?
> best avoided. All those keyword arguments! I intentionally excluded
> tham from Emacs and I am not going to let them in.
I don't want to be impolite, but they are already in; via cl-lib.el.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-09-06 5:04 ` Arthur Miller
@ 2023-09-06 11:29 ` Alan Mackenzie
2023-09-08 2:00 ` Arthur Miller
0 siblings, 1 reply; 54+ messages in thread
From: Alan Mackenzie @ 2023-09-06 11:29 UTC (permalink / raw)
To: Arthur Miller; +Cc: Richard Stallman, luangruo, emacs-devel
Hello, Arthur.
On Wed, Sep 06, 2023 at 07:04:43 +0200, Arthur Miller wrote:
> Richard Stallman <rms@gnu.org> writes:
> > [[[ 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. ]]]
> > > Would you please stop arguing for rewriting Emacs in Common Lisp? It
> > > is a non-starter.
> > > It would be an enormouse job -- including rewriting the Emacs Lisp
> > > Referance Manual.
> > Also, there are aspects of Common Lisp which i rejected as clumsy and
> With all respect to you, but sound to me like an emotional argument, not
> a rational one.
It's a rational argument expressed in emotional terms for simplicity.
> I don't know why you reject them as clumsy, but why does it matter to us
> if a tool includes features we don't use?
It matters a very great deal. In practice you cannot avoid "using" these
features if you have to understand or debug somebody else's code.
> I don't know if I understand it correctly, but CL was made so other
> Lisps can be abstracted on top of it; so we use those features to
> abstract stuff on top of those lengthy verbose functions? In other
> words we can hide those keyword params behind elispy abstractions if we
> don't like them?
That's complexity and bloat. Far better not to have them in the first
place.
> > best avoided.
> Why are they best avoided? Is there some technical reason or is it
> psychological?
It's because they are not needed. Bear in mind, Common Lisp is a massive
language, much like C++ or PL/1 or Algol-68. With such a language,
nobody uses all of it (it's just too big), but everybody has her own
personal subset. This creates difficulty when somebody else has to
understand that first hacker's code.
CL is a niche language; it has not captured the hacker mindset. I think
it is just too big and too unwieldy.
> > best avoided. All those keyword arguments! I intentionally excluded
> > tham from Emacs and I am not going to let them in.
> I don't want to be impolite, but they are already in; via cl-lib.el.
Yes. There was a time not so long ago when cl.el was banned from use in
our Lisp code, except for at compile time. Our Emacs Lisp was small,
simple to understand, and easy to learn. Now things in cl-lib.el get
used as if they are just a normal part of Emacs Lisp. Our language is
thus MUCH more difficult to understand, perhaps by a factor of somewhere
between 3 and 10. When perusing even established parts of Emacs I groan
inwardly every time I encounter one of these needless cl-lib features.
It stops me dead, forcing me to consult doc strings (which are often
missing and often inadequate even when they are present) or even manuals.
Were we to rewrite Emacs in Common Lisp, these things would get worse
fairly quickly.
--
Alan Mackenzie (Nuremberg, Germany).
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-09-06 11:29 ` Alan Mackenzie
@ 2023-09-08 2:00 ` Arthur Miller
2023-09-08 15:38 ` [External] : " Drew Adams
0 siblings, 1 reply; 54+ messages in thread
From: Arthur Miller @ 2023-09-08 2:00 UTC (permalink / raw)
To: Alan Mackenzie; +Cc: Richard Stallman, luangruo, emacs-devel
Alan Mackenzie <acm@muc.de> writes:
> Hello, Arthur.
>
> On Wed, Sep 06, 2023 at 07:04:43 +0200, Arthur Miller wrote:
>> Richard Stallman <rms@gnu.org> writes:
>
>> > [[[ 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. ]]]
>
>> > > Would you please stop arguing for rewriting Emacs in Common Lisp? It
>> > > is a non-starter.
>
>> > > It would be an enormouse job -- including rewriting the Emacs Lisp
>> > > Referance Manual.
>
>> > Also, there are aspects of Common Lisp which i rejected as clumsy and
>
>> With all respect to you, but sound to me like an emotional argument, not
>> a rational one.
>
> It's a rational argument expressed in emotional terms for simplicity.
What you basicaly say: it somehow is a summarization of some more
advanced/complicated reasons which can't be explained, but have to be
expressed in the term "I don't like it" for the simplicity?
I don't think it is a rational argument, but I explicitly didn't want to
speculate why RMS feels so, but asked him to clarify for pure respect
for him as a person. You can try to teach me why is it a rational
argument and why it has to be expressed in emotional terms for
simplicity, and I promise I'll try to understand it as best as I can,
but I have hard time to see such an explanation, because the argument is
truly just an opinion.
CL for sure has things that in retrospect can be debated about, but I
don't think keyword arguments are one of those.
Also note that keyword arguments, or at least similar principle is used
in other parts of Emacs, not just cl-lib; for example look at
define-minor-mode. While define-minor-mode macro does not use "&key" as
an explicit keyword, the arguments to it are a plist which basicaly
gives you the very same effect. The "new" defvar-keymap is another
example.
Keyword arguments are undeniably useful because they let us omit
arguments we are not interested in, and type only the ones we are
interested in. I don't see how they complicate a Lisp by much; we have
&rest and &optional so what is problem having &key?
In my personal opinion it is by far more clumsy to have two defun
macros, and to prefix one with cl- for no good reason at all; and than
have to explain for users why they are two different versions, how they
differ, when they should use each, why would they like to use one or
another etc. If ordinary "defun" was simply upgraded to act as cl-defun,
potential user dilemas and explanations would be avoided.
>> I don't know why you reject them as clumsy, but why does it matter to us
>> if a tool includes features we don't use?
>
> It matters a very great deal. In practice you cannot avoid "using" these
> features if you have to understand or debug somebody else's code.
In practice most of code will use some common part of the language, and
relatively little code will use some specialized parts. In a big
language that targets many different kind of developers, there will
always be features that are needed by some developers but not by
all. Falacy in your, by now very tired and wornout argument, is the
assumption that everyone will use everything in the language all the
time, which certainly isn't the case.
Interestingly, yesterday why commuting home after the work, I have heard
a talk by Stroustrup, quite recent just a few week old:
https://www.youtube.com/watch?v=eo-4ZSLn3jc
The talk is more or less about that very argument: why is C++ so big and
why are there so many features in c++. (If the link gets removed search
on Stroustrup C++ 2023). I think that was one of better Stroustrup's
talks, definitely worth watching.
There is also an incredibly inspirational talk by Steel (search on
"Growing the Language"); I have seen it just a few weeks ago myself:
https://www.youtube.com/watch?v=lw6TaiXzHAE
Observe that Steel gave us the "most minimal" and "elegant" Lisp as
Schemer's like to think of Scheme, which is probably important to
remember in the context of this discussion. If you don't watch it, the
essence is in this summary, and in my opinion is really a clever
insight:
"Over the last quarter-century Guy Steele has been convinced that trying
to design a complete and perfect programming language is the worst thing
you can do. A programming language (including its associated libraries)
must grow over time as its user community and its development community
grow. This is a different situation from 25 years ago, when all such
communities were relatively small. The difference is a problem of
scale. As a result, programming language design now and in the future is
necessarily as much a matter of social engineering as technical
engineering and must rely more on a set of general principles than on a
set of specific technical decisions."
>> I don't know if I understand it correctly, but CL was made so other
>> Lisps can be abstracted on top of it; so we use those features to
>> abstract stuff on top of those lengthy verbose functions? In other
>> words we can hide those keyword params behind elispy abstractions if we
>> don't like them?
>
> That's complexity and bloat. Far better not to have them in the first
> place.
Complexity and bloat by which metric?
Emacs has long time ago exceeded CL in numbers of "core functions". By
the time I have extracted all Lisp defuns from the C core, a couple of
months ago or so, it was ~1800 functions in C core. That is by far many
more than what CL standard defines. I know that some of Emacs devs are
lurking on Reddit behind pseudonims, I don't know if you are one of
them, but there are also quite many users who consider Emacs to be quite
bloated and would like many of some older parts to be expunded out of
the core.
Anyway, by the nature of Lisp, there are very few actual language
concepts, and there are quite few additional concepts that CL offers
that need support of the system that are not found in Emacs; but most of
additions to the language are actually looking exactly like the language
itself. The nice thing is that, when you write a defun in Lisp, it
becomes part of the language itself, unlike languages like Java, C, C++
etc where users can not extend the language itself since the syntax has
to be encoded in the compiler. In other words, it means, that even if
you don't want it, people can extend it the way they like it, and cl.el
was a proof.
>> > best avoided.
>
>> Why are they best avoided? Is there some technical reason or is it
>> psychological?
>
> It's because they are not needed. Bear in mind, Common Lisp is a massive
I don't know if you agree with me or not, but in order to drive from
Nuremberg to Berlin you certainly don't need AC in a car; but on a hot
summer day, with 40 degrees (celsius) it is very nice to have AC in the
car, isn't it? Sure, keyword arguments are not needed; but they are
handy from time to time. Optional or rest arguments are not needed
either, but they too are nice to have sometimes, aren't they? What
makes keyword arguments more "clumsy" then?
To be honest to you, I really didn't want to answer this mail, because I
see just very same arguments I have seen many, many times before. I had
very much, very same sentiment about C++ as you, and I didn't even know
much of CL at all; I just thought it was big and bloated and didn't want
to use it, untill not so long time ago. Untill perhaps a year or two
ago, when I invested some time in learning more about CL and tried to
understand why things are as they are, not just in CL, but in general;
C++ very much included.
> It's because they are not needed. Bear in mind, Common Lisp is a massiveI
> language, much like C++ or PL/1 or Algol-68. With such a language,
> nobody uses all of it (it's just too big), but everybody has her own
> personal subset. This creates difficulty when somebody else has to
> understand that first hacker's code.
I totally understand you; but I believe this is a bit misguided. For the
first, for the same argument as above, nobody uses the entire language
because they don't need it; not because it is too big. Some parts target
certain specialized domains which are needed by some groups and not by
everyone. I think that is more true for C++ and less for CL, because CL
is not that massive as you are trying to make it. CL is also a child of its
time, just like Emacs, and some parts are probably in need of a
revision, but it certainly stands the proof of time when it comes to
core language principles.
If we look at this:
(defun directory-files (directory &optional full match nosort count)
...)
When you call this function in the code; how easy is to remember the
order and number of arguments? Was it 5 or 6 arguments? I had fortune to
contribute the idea for the 5th argument, and yet I typed by a misstake
the wrong number:
CL-USER> (directory-files "./" nil nil nil nil 5)
; Debugger entered on #<SB-INT:SIMPLE-PROGRAM-ERROR "invalid number of arguments: ~S" {1001E92C63}>
[1] CL-USER>
; Evaluation aborted on #<SB-INT:SIMPLE-PROGRAM-ERROR "invalid number of arguments: ~S" {1001E92C63}>
CL-USER> (directory-files "./" nil nil nil 5)
("alloc.lisp" "buffer.lisp" "callint.lisp" "callproc.lisp" "casefiddle.lisp")
CL-USER>
If I only change &optional to &key:
(defun directory-files (directory &key full match nosort count) ... )
I can now type:
CL-USER> (directory-files "./" :count 5)
("#dired.lisp#" ".#dired.lisp" "alloc.lisp" "buffer.lisp" "callint.lisp")
CL-USER>
How "clumsy" is that? Honestly, I am not trying to be PITA or devil's
advocate or anything like that; but I think that everyone will agree
that the second one is both nicer, less error prone to type and puts
less cognitive load on users to remember or lookup the information.
Just as a remark: by just having it in CL I was able to just go to the
code, and change "optional" for "key", C-x C-e in Sly and I changed the
implementation of "directory-files", nice? For the record if you want to
try it (just a fast hack for the demonstration purpose, needs cl-ppcre lib):
(defun directory-files (directory &key full match nosort count)
(let ((files
(if full
(mapcar #'namestring (uiop:directory-files directory))
(mapcar #'file-namestring (uiop:directory-files directory)))))
(when match
(let ((scanner (ppcre:create-scanner match))
matches)
(dolist (filename files)
(when (ppcre:scan scanner filename)
(push filename matches)))
(setf files matches)))
(unless nosort
(setq files (sort files #'string-lessp)))
(when (and (numberp count) (> count 0))
(when (> count (length files))
(setf count (length files)))
(setf files (subseq files 0 count)))
files))
Observe also that I agree with you; keyword arguments are not needed,
but are very nice to have.
> CL is a niche language; it has not captured the hacker mindset. I think
> it is just too big and too unwieldy.
>
>> > best avoided. All those keyword arguments! I intentionally excluded
>> > tham from Emacs and I am not going to let them in.
>
>> I don't want to be impolite, but they are already in; via cl-lib.el.
>
> Yes. There was a time not so long ago when cl.el was banned from use in
> our Lisp code, except for at compile time. Our Emacs Lisp was small,
> simple to understand, and easy to learn. Now things in cl-lib.el get
> used as if they are just a normal part of Emacs Lisp. Our language is
> thus MUCH more difficult to understand, perhaps by a factor of somewhere
> between 3 and 10. When perusing even established parts of Emacs I groan
> inwardly every time I encounter one of these needless cl-lib features.
> It stops me dead, forcing me to consult doc strings (which are often
> missing and often inadequate even when they are present) or even manuals.
"MUCH more difficult" for whom in which sense?
What you are telling is that "good old times were so much better" which
is just an emotional argument. You are actually just reinforcing the
same sentiment that RMS expressed. I shared that sentiment myself, but I
think it is misguided.
We can certainly speak about "old ways", let us take the or-idiom or how
should I call it: initialization of the default value for optional arguments:
(defun foo (&optional who-am-I)
(let ((who-am-I (or who-am-I "foo")))
(message "I am %s." who-am-I)))
Is that really better than typing:
(cl-defun foo (&optional (who-am-I "foo"))
(message "I am %s." who-am-I))
The user has to learn the idiom, which uses operator "or" to perform
something that visually has nothing to do with the intention of the
code, and also has to type the additional let-form each and every
time. Than the users who are not familiar with the idiom will perhaps
come up with their own version, using setq or some other thing, and you
will really have to think what the user wanted to say with their code if
you had to debug it. Is it better than seing an initialiser and knowing
directly what is the default value and everyone using uniform syntax?
There was a discussion, perhaps a couple of years ago, I think on Emacs
help list, I don't remember the detials, but I think something about
car, cdr, cdar, cddr & co, and using "nth" instead of them. Monnier said a
clever thing there: using those old functions is like writing in
assembler, but without the benefit of additional speed (something in
that sense). I think he was more than correct there. It is much more
clear to say (nth N list), than to chain cars and cdrs together.
A bit further, that really is about abstractions. We can for sure do
lots of stuff manually, without higher-level abstractions; but higher
level abstractions, like using initializer in a defun arguments, help us
convey the meaning more clearly and concize, we can rationalize about
abstractions, and they are probably easier to remember than teaching
people how to use some common pattern or idiom.
I also happened to read the CMUCL manual just yesterday. They have a
nice writing about using structures instead of lists in CL:
"Even if structures weren't more efficient than other representations,
structure use would still be attractive because programs that use
structures in appropriate ways are much more maintainable and robust
than programs written using only lists. For example:
(rplaca (caddr (cadddr x)) (caddr y))
could have been written using structures in this way:
(setf (beverage-flavor (astronaut-beverage x)) (beverage-flavor y))
The second version is more maintainable because it is easier to
understand what it is doing."
https://cmucl.org/downloads/doc/cmu-user-2010-05-03/compiler-hint.html#toc189
> Were we to rewrite Emacs in Common Lisp, these things would get worse
> fairly quickly.
I think you are very, very wrong about that one; on the contrary we
would get some tools that Emacs is lacking to manage the code
complexity, but I don't think they are actually applicable on the
existing code, so they don't matter much. But things certainly wouldn't
get worse. That is just my opinion of course, you can think I am an
idiot and I can be wrong, but at least give me a reason to change my
mind that isn't based on subjective opinion.
^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [External] : Re: Shrinking the C core
2023-09-08 2:00 ` Arthur Miller
@ 2023-09-08 15:38 ` Drew Adams
2023-09-09 11:55 ` Arthur Miller
2023-09-11 0:40 ` Richard Stallman
0 siblings, 2 replies; 54+ messages in thread
From: Drew Adams @ 2023-09-08 15:38 UTC (permalink / raw)
To: Arthur Miller, Alan Mackenzie
Cc: Richard Stallman, luangruo@yahoo.com, emacs-devel@gnu.org
FWIW, +1 for your mail, Arthur -
pretty much each of the points you made.
___
As one who's used CL (long ago) but is
no expert about it or Elisp or Lisp
generally, I happen to agree about the
usefulness of keyword args _for users_.
I can't really speak to implementation,
compilation, maintenance, etc., all of
which are of course also important.
AFAIK there has never been a real, open,
serious discussion about keyword args
for Elisp. And (I think) I've always
respected the decision to not bring up
the question. But I do appreciate it
being at least _presented_, if not put
on the table for outright discussion.
In general, I like that Richard speaks
up and decides, and I generally agree
with his judgments as helmsman. But on
this one my own experience tells me
something different.
Not that I have any interesting opposing
arguments. Nor do I want to argue about
this. But my experience with CL has led
me to appreciate the ease and handiness
of using keyword args.
Argument order, and the need to provide
all args up through the last optional
one you really want to provide, are an
unnecessary burden on human readers of
code. Writers too, of course, but it's
more important that code be clear for
readers (including writers as readers).
Unnecessary burden. So Occam asks "Why
then?". In his role as _implementer_ of
a language Occam might ask "Why bother
with keywords args?" But in his role as
user I think his question would be "Why
always need to know & respect arg order?"
I also haven't noticed that having named
arguments is detrimental to code that
analyses or generates code. I have some,
but less, experience with that - maybe
it's something to consider; dunno.
___
That's likely all I'll say about this.
Just one opinion. Keyword args can be
incredibly useful _for users_.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-08 15:38 ` [External] : " Drew Adams
@ 2023-09-09 11:55 ` Arthur Miller
2023-09-09 12:55 ` Eli Zaretskii
2023-09-10 0:09 ` Drew Adams
2023-09-11 0:40 ` Richard Stallman
1 sibling, 2 replies; 54+ messages in thread
From: Arthur Miller @ 2023-09-09 11:55 UTC (permalink / raw)
To: Drew Adams
Cc: Alan Mackenzie, Richard Stallman, luangruo@yahoo.com,
emacs-devel@gnu.org
Drew Adams <drew.adams@oracle.com> writes:
> FWIW, +1 for your mail, Arthur -
> pretty much each of the points you made.
> ___
>
> As one who's used CL (long ago) but is
> no expert about it or Elisp or Lisp
> generally, I happen to agree about the
> usefulness of keyword args _for users_.
Interestingly, how things can be percieved wrongly over the wire.
I always percieved you as an CL veteran and expert :).
> I can't really speak to implementation,
> compilation, maintenance, etc., all of
> which are of course also important.
>
> AFAIK there has never been a real, open,
> serious discussion about keyword args
> for Elisp. And (I think) I've always
> respected the decision to not bring up
> the question. But I do appreciate it
> being at least _presented_, if not put
> on the table for outright discussion.
>
> In general, I like that Richard speaks
> up and decides, and I generally agree
> with his judgments as helmsman. But on
> this one my own experience tells me
> something different.
>
> Not that I have any interesting opposing
> arguments. Nor do I want to argue about
> this. But my experience with CL has led
> me to appreciate the ease and handiness
> of using keyword args.
I really didn't want to argue about keyword arguments either, but
Richard brought them up himself. Like you, and probably everyone else
who is familiar with Richards writing through the years, through his
articles and this very mailing list, I am aware of the elephant in the
room, but honestly, I think his friends, Eli and others, are too kind and
would do Richard more favor if they told him when he is dead wrong and
made him to challenge his own view on some questions from time to
time. This reminded me of John Cleese and Faulty Towers, no idea if you
had that in States, but I think every European here knows which episode
I am thinking of at the moment.
> Argument order, and the need to provide
> all args up through the last optional
> one you really want to provide, are an
> unnecessary burden on human readers of
> code. Writers too, of course, but it's
> more important that code be clear for
> readers (including writers as readers).
>
> Unnecessary burden. So Occam asks "Why
> then?". In his role as _implementer_ of
> a language Occam might ask "Why bother
> with keywords args?" But in his role as
> user I think his question would be "Why
> always need to know & respect arg order?"
>
> I also haven't noticed that having named
> arguments is detrimental to code that
> analyses or generates code. I have some,
> but less, experience with that - maybe
> it's something to consider; dunno.
> ___
>
> That's likely all I'll say about this.
> Just one opinion. Keyword args can be
> incredibly useful _for users_.
Thank you, for wording this so concisely. You are much better with
words than me. I am not a good writer, not even in my own language, so
mine explanations and arguments are always long and round-about for some
reason.
Best regards
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-09 11:55 ` Arthur Miller
@ 2023-09-09 12:55 ` Eli Zaretskii
2023-09-09 13:20 ` Arthur Miller
2023-09-10 0:09 ` Drew Adams
1 sibling, 1 reply; 54+ messages in thread
From: Eli Zaretskii @ 2023-09-09 12:55 UTC (permalink / raw)
To: Arthur Miller; +Cc: drew.adams, acm, rms, luangruo, emacs-devel
> From: Arthur Miller <arthur.miller@live.com>
> Cc: Alan Mackenzie <acm@muc.de>, Richard Stallman <rms@gnu.org>,
> "luangruo@yahoo.com" <luangruo@yahoo.com>, "emacs-devel@gnu.org"
> <emacs-devel@gnu.org>
> Date: Sat, 09 Sep 2023 13:55:46 +0200
>
> I really didn't want to argue about keyword arguments either, but
> Richard brought them up himself. Like you, and probably everyone else
> who is familiar with Richards writing through the years, through his
> articles and this very mailing list, I am aware of the elephant in the
> room, but honestly, I think his friends, Eli and others, are too kind and
> would do Richard more favor if they told him when he is dead wrong and
> made him to challenge his own view on some questions from time to
> time.
This comes out quite condescending, FYI. You probably didn't mean
that, but the result is not nice anyway. One more reason to stop this
dispute about personal stylistic preferences, which was futile from
the get-go.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-09 12:55 ` Eli Zaretskii
@ 2023-09-09 13:20 ` Arthur Miller
0 siblings, 0 replies; 54+ messages in thread
From: Arthur Miller @ 2023-09-09 13:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: drew.adams, acm, rms, luangruo, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Alan Mackenzie <acm@muc.de>, Richard Stallman <rms@gnu.org>,
>> "luangruo@yahoo.com" <luangruo@yahoo.com>, "emacs-devel@gnu.org"
>> <emacs-devel@gnu.org>
>> Date: Sat, 09 Sep 2023 13:55:46 +0200
>>
>> I really didn't want to argue about keyword arguments either, but
>> Richard brought them up himself. Like you, and probably everyone else
>> who is familiar with Richards writing through the years, through his
>> articles and this very mailing list, I am aware of the elephant in the
>> room, but honestly, I think his friends, Eli and others, are too kind and
>> would do Richard more favor if they told him when he is dead wrong and
>> made him to challenge his own view on some questions from time to
>> time.
>
> This comes out quite condescending, FYI. You probably didn't mean
> that, but the result is not nice anyway.
No, I certainly didn't mean as patronizing if that is what "condecending".
> that, but the result is not nice anyway. One more reason to stop this
> dispute about personal stylistic preferences, which was futile from
> the get-go.
I agree it is futile.
No problems; thanks for telling me.
^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [External] : Re: Shrinking the C core
2023-09-09 11:55 ` Arthur Miller
2023-09-09 12:55 ` Eli Zaretskii
@ 2023-09-10 0:09 ` Drew Adams
1 sibling, 0 replies; 54+ messages in thread
From: Drew Adams @ 2023-09-10 0:09 UTC (permalink / raw)
To: Arthur Miller
Cc: Alan Mackenzie, Richard Stallman, luangruo@yahoo.com,
emacs-devel@gnu.org
> > FWIW, +1 for your mail, Arthur -
> > pretty much each of the points you made.
> > ___
> >
> > As one who's used CL (long ago) but is
> > no expert about it or Elisp or Lisp
> > generally, I happen to agree about the
> > usefulness of keyword args _for users_.
>
> Interestingly, how things can be percieved wrongly over the wire.
> I always percieved you as an CL veteran and expert :).
Nope. Just a long-ago user. Being around a
long time can sometimes give the impression
of being a veteran.
> I think his friends, Eli and others, are too kind and
> would do Richard more favor if they told him when he
> is dead wrong
I have no reason to think Richard is dead
wrong about whether Elisp should have
keyword args. I just related my (good)
experience with them in CL, as one user,
long ago.
Elisp could of course go in many directions.
That it hasn't taken certain directions I'm
generally thankful for, FWIW. It's not a
bad language, and not every proposal or
imagined change represents real progress. ;-)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-08 15:38 ` [External] : " Drew Adams
2023-09-09 11:55 ` Arthur Miller
@ 2023-09-11 0:40 ` Richard Stallman
2023-09-11 15:10 ` João Távora
` (2 more replies)
1 sibling, 3 replies; 54+ messages in thread
From: Richard Stallman @ 2023-09-11 0:40 UTC (permalink / raw)
To: Drew Adams; +Cc: arthur.miller, acm, luangruo, 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. ]]]
I implemented Common Lisp for the Lisp Machine in 1983.
That included the generic sequence functions with their
many keyword arguments.
In 1984 I wrote Emacs Lisp and decided to omit all that.
I have no regrets. Their absence makes Emacs Lisp easier to use.
Keyword arguments are fine for an unusual, heavyweight operation such
as creating a frame. The sort of function whose doc you need to look
up again each time you use it. When something is as cumbersome as
that, the question of how to pass the arguments is a pile of minor
details that you'll see when you look it up.
But it's a pain in the neck to make simple everyday functions such as
`append' and `length' that cumbersome just for the sake of following a
general system. Part of this system is that the default argument
values follow the system, rather than following the traditional Lisp
functions -- so getting the traditional behavior requires actually
specifying the keyword arguments to override defaults, almost every
time.
Switching to Common Lisp would cause those painful incompatibilities.
It is unacceptable.
Defining the CL functions with a name prefix is ok, because the
traditional Lisp functions are still available compatibly and we don't
have to use the CL functions. This is what we have now.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-11 0:40 ` Richard Stallman
@ 2023-09-11 15:10 ` João Távora
2023-09-11 16:12 ` Drew Adams
` (2 more replies)
2023-09-11 21:09 ` Eric S. Raymond
2023-09-12 2:30 ` Arthur Miller
2 siblings, 3 replies; 54+ messages in thread
From: João Távora @ 2023-09-11 15:10 UTC (permalink / raw)
To: rms; +Cc: Drew Adams, arthur.miller, acm, luangruo, emacs-devel
On Mon, Sep 11, 2023 at 1:40 AM Richard Stallman <rms@gnu.org> wrote:
> Keyword arguments are fine for an unusual, heavyweight operation such
> as creating a frame. The sort of function whose doc you need to look
> up again each time you use it. When something is as cumbersome as
> that, the question of how to pass the arguments is a pile of minor
> details that you'll see when you look it up.
It's possible that in 1984 there weren't any good at-point-documentation
systems that immediately show the available keyword arguments of a given
call being typed. I was very young at the time, so I can't attest to it.
But nowadays such systems exist, including built-in, in Emacs.
But even in the absence of those conveniences, each family of functions
in CL, (say, the sequence manipulating functions) take standard sets
of keyword arguments (like :START, :END, :FROM-END, :KEY, :TEST).
This makes them very easy to remember and makes using e.g. CL's SORT
much more practical than Emacs Lisp 'sort'.
> But it's a pain in the neck to make simple everyday functions such as
> `append' and `length' that cumbersome just for the sake of following a
> general system.
APPEND and LENGTH in Common Lisp do not take keyword arguments,
(nor have they ever?) so I believe your argument is weakened by
criticizing a suggestion that no-one is offering.
Let's look at a traditional Elisp macro define-minor-mode.
According to the CVS history, you created this function in 1997, with
three positional optional arguments. Then more and more arguments
came along. Possibly due to the realization by Emacs developers
around 2000, already more than 20 years ago, that positional arguments
are maintenance hazards, the macro now accepts keyword arguments
(and the positional arguments are actively discouraged).
Unfortunately, because cl-lib.el wasn't used for this particular change,
the aforementioned at-point documentation facilities aren't available,
which, to some of us, would appear just another manifestation of
Greenspun's 10th rule (which I assume everyone in this niche topic
is familar with).
Many other functions with a large amount of optional arguments
(completing-read comes to mind) would be much, much easier
to use with keyword arguments. Without them, we find ourselves
wondering about how many nils to sprinkle before the argument
we want to pass.
João
^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [External] : Re: Shrinking the C core
2023-09-11 15:10 ` João Távora
@ 2023-09-11 16:12 ` Drew Adams
2023-09-11 20:37 ` Tomas Hlavaty
2023-09-15 8:43 ` Emanuel Berg
2 siblings, 0 replies; 54+ messages in thread
From: Drew Adams @ 2023-09-11 16:12 UTC (permalink / raw)
To: João Távora, rms@gnu.org
Cc: arthur.miller@live.com, acm@muc.de, luangruo@yahoo.com,
emacs-devel@gnu.org
I thought my previous post in this thread would
likely be my only such, but I'd like now to add a
point, FWIW.
Richard, you spoke about implementing support for
keyword args in ~CL (Lisp-machine Lisp code that
you wrote), and how you found their presence to be
a bother for implementers and (I think) users.
I mentioned that I appreciated _using_ keyword args
with CL, long ago. I'll add that it was especially
in code that I wrote that I found them useful (as
opposed to their presence in standard CL code).
That is, for _users_ of my code (but including me,
while developing and testing). And especially for
functions that allowed for more than a few args.
In a nutshell, with keyword args a single function
can replace multiple related/similar functions.
And when you have multiple things to juggle, it
helps to name them, and it helps to not need to
address them in a particular order.
Here's an analogy:
Imagine Lisp without &optional args. You'd end by
defining more functions of the same "family".
IME, the same difference applies to the absence of
keyword args. You end up defining more functions,
for the convenience of not having to specifying a
zillion nil args. Plus you have to pay attention
to arg order.
Of course sometimes it makes sense to define a
separate function or two, to cover particular
common use cases. But in general optional args
are handy, and so are keyword args, for the same
reason: many functions in one - a single name to
rule them all. ;-)
Now, if you always _had to_ use keyword args, so
you could _never_ just provide args without names
(in the proper order), then that would definitely
be an unnecessary bother. We probably all agree
about that.
In Lisp all args to functions are evaluated, and
there really is no user-level dependence on the
order of their evaluation. Given that, Occam says
that arg order doesn't matter, and there's no real
_need_ to specify args in an order, filling in nil
args as needed to get to the last optional arg you
need.
From a user point of view, being able to have the
option of specifying an arg by its position OR by
its name is just a plus - I don't see any downside.
From the point of view of a language implementer
things might be different, of course.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-11 15:10 ` João Távora
2023-09-11 16:12 ` Drew Adams
@ 2023-09-11 20:37 ` Tomas Hlavaty
2023-09-11 21:10 ` João Távora
2023-09-15 8:43 ` Emanuel Berg
2 siblings, 1 reply; 54+ messages in thread
From: Tomas Hlavaty @ 2023-09-11 20:37 UTC (permalink / raw)
To: João Távora, rms
Cc: Drew Adams, arthur.miller, acm, luangruo, emacs-devel
On Mon 11 Sep 2023 at 16:10, João Távora <joaotavora@gmail.com> wrote:
> This makes them very easy to remember and makes using e.g. CL's SORT
> much more practical than Emacs Lisp 'sort'.
not really, it seems that CL:SORT is a bad example
the CL spec defines sort like this:
sort sequence predicate &key key => sorted-sequence
stable-sort sequence predicate &key key => sorted-sequence
(btw why two functions and not extra stablep keyword argument?)
it could have been defined as:
sort sequence predicate &optional key => sorted-sequence
stable-sort sequence predicate &optional key => sorted-sequence
and the same could be done in elisp which would be backwards compatible
> Let's look at a traditional Elisp macro define-minor-mode.
the usual CL argument list does not seem to be able to express arguments
of such shape
it looks like whoever extended the original argument list did it
"weirdly" using custom ad-hoc single-use argument list parser.
> are maintenance hazards, the macro now accepts keyword arguments
in CL, the arguments would normally be in a list before body, something
like
(define-minor-mode MODE ([KEYWORD VAL ... ]) [DOC] &rest BODY)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-11 20:37 ` Tomas Hlavaty
@ 2023-09-11 21:10 ` João Távora
2023-09-12 19:52 ` Tomas Hlavaty
0 siblings, 1 reply; 54+ messages in thread
From: João Távora @ 2023-09-11 21:10 UTC (permalink / raw)
To: Tomas Hlavaty; +Cc: rms, Drew Adams, arthur.miller, acm, luangruo, emacs-devel
On Mon, Sep 11, 2023 at 9:37 PM Tomas Hlavaty <tom@logand.com> wrote:
> not really, it seems that CL:SORT is a bad example
The example was for comparing to Emacs's lisp 'sort', where
IMO it's much easier to do
(cl-sort things-having-foo #'< :key #'foo)
than
(sort things-having-foo (lambda (a b) (< (foo a) (foo b))))
As to the advantage of @key key vs &optional key it is -- in my
eyes, at least -- that you already know its meaning from many other
functions.
> (btw why two functions and not extra stablep keyword argument?)
Why not? Maybe that makes passing sort and stable-sort to higher
order functions more practical?
> it could have been defined as:
>
> sort sequence predicate &optional key => sorted-sequence
> stable-sort sequence predicate &optional key => sorted-sequence
>
> and the same could be done in elisp which would be backwards compatible
Sure, but if according to your conjecture Elisp's grew a &optional
arg, why couldn't it grow a &key arg and be backwards compatible?
> > Let's look at a traditional Elisp macro define-minor-mode.
>
> the usual CL argument list does not seem to be able to express arguments
> of such shape
>
> it looks like whoever extended the original argument list did it
> "weirdly" using custom ad-hoc single-use argument list parser.
Quite likely the cl machinery wasn't available at the time... But yes,
Greenspun's 10th.
> > are maintenance hazards, the macro now accepts keyword arguments
>
> in CL, the arguments would normally be in a list before body, something
> like
>
> (define-minor-mode MODE ([KEYWORD VAL ... ]) [DOC] &rest BODY)
OK, but this is irrelevant. This is a macro, not a function.
For all practical purposes it was extended with keyword arguments.
In fact you could have used cl-lib's cl-destructuring-bind.
João
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-11 21:10 ` João Távora
@ 2023-09-12 19:52 ` Tomas Hlavaty
2023-09-12 20:52 ` João Távora
0 siblings, 1 reply; 54+ messages in thread
From: Tomas Hlavaty @ 2023-09-12 19:52 UTC (permalink / raw)
To: João Távora
Cc: rms, Drew Adams, arthur.miller, acm, luangruo, emacs-devel
On Mon 11 Sep 2023 at 22:10, João Távora <joaotavora@gmail.com> wrote:
> On Mon, Sep 11, 2023 at 9:37 PM Tomas Hlavaty <tom@logand.com> wrote:
>> not really, it seems that CL:SORT is a bad example
>
> The example was for comparing to Emacs's lisp 'sort', where
> IMO it's much easier to do
>
> (cl-sort things-having-foo #'< :key #'foo)
>
> than
>
> (sort things-having-foo (lambda (a b) (< (foo a) (foo b))))
That has nothing to do with &key.
It has everything to do with the lack of the KEY argument
and the KEY argument could as well be &optional instead of &key.
If you find lack of the key argument "much not easier", you can define
your own sort, something like:
(defun sort3 (seq pred key)
(sort seq (lambda (a b)
(funcall pred
(funcall key a)
(funcall key b)))))
where
(sort3 things-having-foo #'< #'foo)
is "much easier to do" than
(cl-sort things-having-foo #'< :key #'foo)
or
(sort things-having-foo (lambda (a b) (< (foo a) (foo b))))
Additionally, you'll get much nicer tool support automatically,
e.g. autodoc tells me:
sort3: (SEQ PRED KEY)
cl-sort: (SEQ PREDICATE [KEYWORD VALUE]...)
One can see that autodoc for cl-sort is severely crippled.
> As to the advantage of @key key vs &optional key it is -- in my
> eyes, at least -- that you already know its meaning from many other
> functions.
The point Richard raised was that your "many other functions" with &key
are bad way of doing it.
Simply naming the argument KEY would achieve the same goal of already
knowing its meaning from many other functions. Making it &key does not
change that.
>> (btw why two functions and not extra stablep keyword argument?)
>
> Why not? Maybe that makes passing sort and stable-sort to higher
> order functions more practical?
That speculation does not sound plausible.
By that logic, CL would probably define 4 functions:
sort sequence predicate => sorted-sequence
sort3 sequence predicate key => sorted-sequence
stable-sort sequence predicate => sorted-sequence
stable-sort3 sequence predicate key => sorted-sequence
>> > Let's look at a traditional Elisp macro define-minor-mode.
>>
>> the usual CL argument list does not seem to be able to express arguments
>> of such shape
>>
>> it looks like whoever extended the original argument list did it
>> "weirdly" using custom ad-hoc single-use argument list parser.
>
> Quite likely the cl machinery wasn't available at the time... But yes,
> Greenspun's 10th.
>
>> > are maintenance hazards, the macro now accepts keyword arguments
>>
>> in CL, the arguments would normally be in a list before body, something
>> like
>>
>> (define-minor-mode MODE ([KEYWORD VAL ... ]) [DOC] &rest BODY)
>
> OK, but this is irrelevant. This is a macro, not a function.
> For all practical purposes it was extended with keyword arguments.
> In fact you could have used cl-lib's cl-destructuring-bind.
No, that's missing the point. CL itself is not able to express the
argument list structure in the shape it is implemented in
define-minor-mode. You need custom argument parser anyway.
autodoc for define-minor-mode is also useless:
define-minor-mode: (MODE DOC [KEYWORD VAL ... &rest BODY])
The way define-minor-mode sneaks in keyword arguments is pretty bad. It
implements custom argument list parser and makes tools that understand
and work with argument lists useless, which causes extra manual work in
other areas. If there was a unified argument list parser implemented in
one place and used consistently, it would avoid lots of manual work.
Back to the [KEYWORD VAL ... ] example, putting the argument list of the
macro into an extra list would allow one to use unified argument list
parser, but the way define-minor-mode arguments are specified at the
moment, CL:DESTRUCTURING-BIND cannot destructure such structure (&key
before &rest/&body is malformed).
Another example, take &body as opposed to &rest. It automatically
declares the intent and how the indentation is meant to be computed.
With &rest indentation needs to be specified individually and manually
per case. Lack of &body in elisp is annoying inconvenience. Example:
(with-help-window BUFFER-OR-NAME &rest BODY) has (declare (indent 1))
which would not be needed if it was (with-help-window BUFFER-OR-NAME
&body BODY).
I think that rather than arguing about keyword arguments only, it would
be better to push for a unified argument list format which would be
followed, understood and supported by relevant tools. So far, argument
list structure in elisp grew into ad-hoc mess which one needs to decode
manually from docstring on case by case basis; and no amount of CL would
help.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-12 19:52 ` Tomas Hlavaty
@ 2023-09-12 20:52 ` João Távora
0 siblings, 0 replies; 54+ messages in thread
From: João Távora @ 2023-09-12 20:52 UTC (permalink / raw)
To: Tomas Hlavaty; +Cc: rms, Drew Adams, arthur.miller, acm, luangruo, emacs-devel
On Tue, Sep 12, 2023 at 8:52 PM Tomas Hlavaty <tom@logand.com> wrote:
> It has everything to do with the lack of the KEY argument
> and the KEY argument could as well be &optional instead of &key.
Yes, it could, but should it? I think not, because consistency.
You think yes, because whatever, so let's just disagree.
> If you find lack of the key argument "much not easier", you can define
> your own sort, something like:
The point with having good library functions is that the user doesn't
need to define her ad-hoc versions.
> One can see that autodoc for cl-sort is severely crippled.
That's a problem with autodoc and cl-sort's definition, not its protocol.
Functions defined with cl-func are much better and autodoc functionality
for SLIME/SLY is spot on and detects the correct argument. This is
no technical hurdle.
João
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-11 15:10 ` João Távora
2023-09-11 16:12 ` Drew Adams
2023-09-11 20:37 ` Tomas Hlavaty
@ 2023-09-15 8:43 ` Emanuel Berg
2 siblings, 0 replies; 54+ messages in thread
From: Emanuel Berg @ 2023-09-15 8:43 UTC (permalink / raw)
To: emacs-devel
João Távora wrote:
> Many other functions with a large amount of optional
> arguments (completing-read comes to mind) would be much,
> much easier to use with keyword arguments. Without them, we
> find ourselves wondering about how many nils to sprinkle
> before the argument we want to pass.
Agreed, it is better with keyword arguments than a long list
of nils because of optional arguments.
But it is better yet to not have the functions take so many
arguments in the first place, but to split them up and have
the function name be more specific what is going to happen.
Sometimes this just doesn't happen, it's life and I have
a hard time seeing any situation (long list of nils for
optional arguments vs. keywords) being a real problem
to anyone?
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-11 0:40 ` Richard Stallman
2023-09-11 15:10 ` João Távora
@ 2023-09-11 21:09 ` Eric S. Raymond
2023-09-12 2:05 ` Arthur Miller
2023-09-12 4:38 ` Gerd Möllmann
2023-09-12 2:30 ` Arthur Miller
2 siblings, 2 replies; 54+ messages in thread
From: Eric S. Raymond @ 2023-09-11 21:09 UTC (permalink / raw)
To: Richard Stallman; +Cc: Drew Adams, arthur.miller, acm, luangruo, emacs-devel
Richard Stallman <rms@gnu.org>:
> Switching to Common Lisp would cause those painful incompatibilities.
> It is unacceptable.
I did some checking into this a few weeks ago and even wrote a bit of Lisp to do
an audit. There are other reasons I decided to get up to speed on Common Lisp
recently, and because I have Emacs Lisp engraved on my forebrain this interested
me in getting a good grasp on how incompatible with SBCL it actally is.
Count of elisp core functions: 1476
Total SBCL/elisp function name collisions: 145
Primitives identical in elisp and SBCL: 116
Primitives not known identical: 28
The first two lines are crunched from querying SBCL's symbol list and
groveling through the Emacs sourcefiles; I can supply the SBCL code I
write to do this if anybody cares.
The second two lines are from me reading the SBCL documentation a lot;
I needed immediate motivation to do that and this was a good one.
I was able to write trivial implementations for 15 of those 28 collisions.
The 14 I didn't implement are these:
(require read-char read random process-status process-plist print
princ prin1-to-string prin1 load documentation defvar aref)
What this means is that it would, in principle, be possible to write
an SBCL core that implements all of the Emacs primitives, with only a rather
small amount of shim code required to make existing elisp code execute
in an environment where it thinks it sees *all* elisp primitives.
The code would look something like this, where I have deleted all but one emulation
to showcase setting up the emulation environment.
;; Implement functions shared between CL and elisp in an elisp-like way
(defun elisp-append (&rest sequences)
"(append &rest SEQUENCES)
Probably introduced at or before Emacs version 18.
This function does not change global state, including the match data.
Concatenate all the arguments and make the result a list.
The result is a list whose elements are the elements of all the arguments.
Each argument may be a list, vector or string.
The last argument is not copied, just used as the tail of the new list."
(apply 'append (mapcar
(lambda (it)
(if (listp it) it (listp it)))
sequences))
)
(defmacro within-elisp (form)
"Evaluate FORM in an environment with elisp behavior."
`(flet ((append #'emacs-append)
(delete-file-internal #'elisp-delete-file-internal)
(eval #'elisp-eval)
(format #'elisp-format)
(intern #'elisp-intern)
(make-hash-table #'elisp-make-hash-table)
(make-string #'elisp-make-string)
(rename-file #'elisp-rename-file)
(sort #'elisp-sort)
(string #'elisp-string)
(string-equal #'elisp-string-equal)
(string-lessp #'elisp-string-lessp)
(symbol-value #'elisp-symbol-value)
(type-of #'elisp-type-of)
(unintern #'elisp-unintern)
(yes-or-no-p #'elisp-yes-or-no-p)
)
,form)
)
With this encapsulation, "painful incompatiblities" between elisp and
a core written in SBCL would never need be visible to anyone who put
an .el extension on their code to tell the core it should be executed
using within-elisp.
I'm not minimizing the amount of work an SBCL core would take,
there's a lot of devil in the details of 1476 + 14 primitive
functions. Nor am I interested in joining a political argument
about whether it should be done; I have too much else on my
plate for that.
But it could be done. There is a technical path forward to it.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-11 21:09 ` Eric S. Raymond
@ 2023-09-12 2:05 ` Arthur Miller
2023-09-12 4:38 ` Gerd Möllmann
1 sibling, 0 replies; 54+ messages in thread
From: Arthur Miller @ 2023-09-12 2:05 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: Richard Stallman, Drew Adams, acm, luangruo, emacs-devel
"Eric S. Raymond" <esr@thyrsus.com> writes:
> Richard Stallman <rms@gnu.org>:
>> Switching to Common Lisp would cause those painful incompatibilities.
>> It is unacceptable.
>
> I did some checking into this a few weeks ago and even wrote a bit of Lisp to do
> an audit. There are other reasons I decided to get up to speed on Common Lisp
> recently, and because I have Emacs Lisp engraved on my forebrain this interested
> me in getting a good grasp on how incompatible with SBCL it actally is.
>
> Count of elisp core functions: 1476
> Total SBCL/elisp function name collisions: 145
> Primitives identical in elisp and SBCL: 116
> Primitives not known identical: 28
>
> The first two lines are crunched from querying SBCL's symbol list and
> groveling through the Emacs sourcefiles; I can supply the SBCL code I
> write to do this if anybody cares.
>
> The second two lines are from me reading the SBCL documentation a lot;
> I needed immediate motivation to do that and this was a good one.
>
> I was able to write trivial implementations for 15 of those 28 collisions.
> The 14 I didn't implement are these:
>
> (require read-char read random process-status process-plist print
> princ prin1-to-string prin1 load documentation defvar aref)
>
> What this means is that it would, in principle, be possible to write
> an SBCL core that implements all of the Emacs primitives, with only a rather
> small amount of shim code required to make existing elisp code execute
> in an environment where it thinks it sees *all* elisp primitives.
>
> The code would look something like this, where I have deleted all but one emulation
> to showcase setting up the emulation environment.
>
> ;; Implement functions shared between CL and elisp in an elisp-like way
>
> (defun elisp-append (&rest sequences)
> "(append &rest SEQUENCES)
>
> Probably introduced at or before Emacs version 18.
> This function does not change global state, including the match data.
>
> Concatenate all the arguments and make the result a list.
> The result is a list whose elements are the elements of all the arguments.
> Each argument may be a list, vector or string.
> The last argument is not copied, just used as the tail of the new list."
> (apply 'append (mapcar
> (lambda (it)
> (if (listp it) it (listp it)))
> sequences))
> )
>
> (defmacro within-elisp (form)
> "Evaluate FORM in an environment with elisp behavior."
> `(flet ((append #'emacs-append)
> (delete-file-internal #'elisp-delete-file-internal)
> (eval #'elisp-eval)
> (format #'elisp-format)
> (intern #'elisp-intern)
> (make-hash-table #'elisp-make-hash-table)
> (make-string #'elisp-make-string)
> (rename-file #'elisp-rename-file)
> (sort #'elisp-sort)
> (string #'elisp-string)
> (string-equal #'elisp-string-equal)
> (string-lessp #'elisp-string-lessp)
> (symbol-value #'elisp-symbol-value)
> (type-of #'elisp-type-of)
> (unintern #'elisp-unintern)
> (yes-or-no-p #'elisp-yes-or-no-p)
> )
> ,form)
> )
>
> With this encapsulation, "painful incompatiblities" between elisp and
> a core written in SBCL would never need be visible to anyone who put
> an .el extension on their code to tell the core it should be executed
> using within-elisp.
There is a little bit more than just this; but that one was very clever
to smooth out basic differences. It all depends on the ambition of
course. I do wrap cl funcitons and re-implement some of those that are
missing in CL just to be able to attach the doc strings to symbols, and
counting on sbcl inlining to remove the function call. I am not sure yet
if it is a good strategy, but I can do it relatively automated. Looks
like this:
(defun take (n list)
"Return the first N elements of LIST.
If N is zero or negative, return nil.
If N is greater or equal to the length of LIST, return LIST (or a copy)."
;; todo - this can probably be done without taking the length of the list
(cl:when (cl:> n 0)
(cl:let ((l (cl:length list)))
(when (cl:> n l) (setf n l))
(cl:subseq list 0 n))))
(defun ntake (n list)
"Modify LIST to keep only the first N elements.
If N is zero or negative, return nil.
If N is greater or equal to the length of LIST, return LIST unmodified.
Otherwise, return LIST after truncating it."
(cl:when (cl:> n 0)
(cl:let ((l list))
(eli:while (cl:and (cl:> n 1) (cl:cdr l))
(cl:setf l (cl:cdr l))
(cl:decf n))
(cl:rplacd l nil)
list)))
(declaim (inline nthcdr))
(defun nthcdr (n list)
"Take cdr N times on LIST, return the result."
(cl:nthcdr n list))
(declaim (inline nth))
(defun nth (n list)
"Return the Nth element of LIST.
N counts from zero. If LIST is not that long, nil is returned."
(cl:nth n list))
But tere is more than just functions and macros.
The reader needs some help; Emacs uses different syntax for characters
and escapes for example; ? vs #\, but the escape syntax is were a real
hear pulling is. Also Emacs does not have character type but basically
uses whatever int comes out of C and thus Emacs API can do arithmetic
operaions and comparisons on characters whereas in CL they have to use
character specific operators. I have implemented the reader to
understand ? and escapes and to spit out integer codes instead of cl
characters so I don't need to dispatch on each mathematical operation.
There is still more, "markers are numbers" in Emacs, so mathematical
operations are applicable to those as well. I haven't decided if I will
do same as they do in C sources or I'll try to implement static dispatch
for generic functions and have mathematical operations as generic
functions, I have to test how it works, but there are other things like
those that have to be taken care of. And there is more, that is
just the tip of the iceberg :).
I am also talking only about lisp implemented in C core. There weould be
need to do some work on the elisp side too; eieo, cl-lib, defun/defmacro,
stuff like that, but that is probably by far lesser and easier to fix.
> I'm not minimizing the amount of work an SBCL core would take,
> there's a lot of devil in the details of 1476 + 14 primitive
> functions. Nor am I interested in joining a political argument
> about whether it should be done; I have too much else on my
> plate for that.
Yes, something like that; it is volumous and lots of work, for one
person probably impossible, but it is not impossible to do.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-11 21:09 ` Eric S. Raymond
2023-09-12 2:05 ` Arthur Miller
@ 2023-09-12 4:38 ` Gerd Möllmann
2023-09-12 5:48 ` Arthur Miller
1 sibling, 1 reply; 54+ messages in thread
From: Gerd Möllmann @ 2023-09-12 4:38 UTC (permalink / raw)
To: Eric S. Raymond
Cc: Richard Stallman, Drew Adams, arthur.miller, acm, luangruo,
emacs-devel
"Eric S. Raymond" <esr@thyrsus.com> writes:
> But it could be done. There is a technical path forward to it.
Which would have to cope with buffer-local bindings.
Just saying :-).
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-12 4:38 ` Gerd Möllmann
@ 2023-09-12 5:48 ` Arthur Miller
0 siblings, 0 replies; 54+ messages in thread
From: Arthur Miller @ 2023-09-12 5:48 UTC (permalink / raw)
To: Gerd Möllmann
Cc: Eric S. Raymond, Richard Stallman, Drew Adams, acm, luangruo,
emacs-devel
Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
>
> > But it could be done. There is a technical path forward to it.
>
> Which would have to cope with buffer-local bindings.
> Just saying :-).
I think they can be dealt with in at least two different ways; but I haven't got
so far yet, so I might be wrong.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-11 0:40 ` Richard Stallman
2023-09-11 15:10 ` João Távora
2023-09-11 21:09 ` Eric S. Raymond
@ 2023-09-12 2:30 ` Arthur Miller
2023-09-12 12:15 ` Emanuel Berg
` (3 more replies)
2 siblings, 4 replies; 54+ messages in thread
From: Arthur Miller @ 2023-09-12 2:30 UTC (permalink / raw)
To: Richard Stallman; +Cc: Drew Adams, acm, luangruo, emacs-devel
Richard Stallman <rms@gnu.org> writes:
> [[[ 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. ]]]
>
> I implemented Common Lisp for the Lisp Machine in 1983.
> That included the generic sequence functions with their
> many keyword arguments.
>
> In 1984 I wrote Emacs Lisp and decided to omit all that.
> I have no regrets. Their absence makes Emacs Lisp easier to use.
Thank you for explanation and clarficiation. Now at least I understand
why you don't like them.
> Keyword arguments are fine for an unusual, heavyweight operation such
> as creating a frame. The sort of function whose doc you need to look
> up again each time you use it. When something is as cumbersome as
> that, the question of how to pass the arguments is a pile of minor
> details that you'll see when you look it up.
>
> But it's a pain in the neck to make simple everyday functions such as
> `append' and `length' that cumbersome just for the sake of following a
> general system. Part of this system is that the default argument
> values follow the system, rather than following the traditional Lisp
> functions -- so getting the traditional behavior requires actually
> specifying the keyword arguments to override defaults, almost every
> time.
Of course, but nobody suggests it is all-in. `length' is not a keyworded
in CL either. It would be madness to do something like naming all
arguments in all functions. But it is convenient to have keywords in
some places, like for example in define-minor-mode or make-process, or
even "new" define-keymap.
> Switching to Common Lisp would cause those painful incompatibilities.
> It is unacceptable.
>
> Defining the CL functions with a name prefix is ok, because the
> traditional Lisp functions are still available compatibly and we don't
> have to use the CL functions. This is what we have now.
If cl-lib was loaded into the lisp image, we could even rename cl-defun
to defun, after we have initialized all the other stuff that goes into
the dump, and have "upgraded" vesion of defun and would be fully
compatible with traditional Lisp functions. We could even go further and
remove cl- prefix from bunch of symbols to make them less cumbersome to
use, and everything would stil be compatible with traditional Lisp
functions.
I think there is a thing that makes Lisp a bit special compared to other
programming languages, and Steel mentions it briefly in his legendary
talk: anyone can add a new feature to the language and it becomes part
of the vocabulary without distinction from the built-in stuff. Keyword
arguments does not require anything special from the C runtime, and we
see them pop-up in different forms in elisp. Perhaps elisp would be
better off to accept them and make cl-defun the norm, instead of seing
macros like define-minor-mode re-implement the technique and some other
macro possibly do something similar which leads to more less maintanable
code.
But that is just loud thinking, since my point wasn't to suggest any
changes, I just wanted to understand why you didn't like keyword
arguments per se, so thank you very much for the answer.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-12 2:30 ` Arthur Miller
@ 2023-09-12 12:15 ` Emanuel Berg
2023-09-12 12:32 ` Emanuel Berg
` (2 subsequent siblings)
3 siblings, 0 replies; 54+ messages in thread
From: Emanuel Berg @ 2023-09-12 12:15 UTC (permalink / raw)
To: emacs-devel
We should extend the current design so that Emacs is
multi-threaded, for this to happen we should agree on a model
how this is supposed to be done, and after that it is just
a matter what needs to be done and what parts need to be
adopted to realize that model.
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-12 2:30 ` Arthur Miller
2023-09-12 12:15 ` Emanuel Berg
@ 2023-09-12 12:32 ` Emanuel Berg
2023-09-12 19:57 ` Tomas Hlavaty
2023-09-13 0:00 ` Richard Stallman
3 siblings, 0 replies; 54+ messages in thread
From: Emanuel Berg @ 2023-09-12 12:32 UTC (permalink / raw)
To: emacs-devel
Arthur Miller wrote:
> Of course, but nobody suggests it is all-in. `length' is not
> a keyworded in CL either. It would be madness to do
> something like naming all arguments in all functions. But it
> is convenient to have keywords in some places [...]
Keywords typically make for shorter interfaces and function
calls that communicate more, however the shorter interface
advantage and the need to have function calls to communicate
more should be put against the typical downside with this
style, which is very long and complicated functions that do
a lot more than they should, often.
And, because very long functions isn't good style anyway,
those should probably be split up - and if they are split up,
the interfaces will be shorter and the style clear that way
instead, so the need for keywords to do that will also be
reduced or disappear, really.
>> Defining the CL functions with a name prefix is ok, because
>> the traditional Lisp functions are still available
>> compatibly and we don't have to use the CL functions.
>> This is what we have now.
>
> If cl-lib was loaded into the lisp image, we could even
> rename cl-defun to defun, after we have initialized all the
> other stuff that goes into the dump, and have "upgraded"
> vesion of defun and would be fully compatible with
> traditional Lisp functions. We could even go further and
> remove cl- prefix from bunch of symbols to make them less
> cumbersome to use, and everything would stil be compatible
> with traditional Lisp functions.
Indeed, that could be done for every cl-X case where X is
a non-cl-lib Elisp function and cl-X already does everything
X does with the same interface. Those could be cancelled out.
For the cases where there is no such X outside of cl-lib, e.g.
`cl-incf' and `cl-decf' (no "incf" or "decf" anymore?) the
cl-lib prefix could also be dropped. Another example is
`cl-loop'. One could solve this with aliases, possibly.
Because yes, it looks a bit strange that such rudimentary
stuff has to be prefixed to note their belonging to some
particular implementation or library, and even more so when
there isn't any competition or alternative, even?
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-12 2:30 ` Arthur Miller
2023-09-12 12:15 ` Emanuel Berg
2023-09-12 12:32 ` Emanuel Berg
@ 2023-09-12 19:57 ` Tomas Hlavaty
2023-09-13 0:00 ` Richard Stallman
3 siblings, 0 replies; 54+ messages in thread
From: Tomas Hlavaty @ 2023-09-12 19:57 UTC (permalink / raw)
To: Arthur Miller, Richard Stallman; +Cc: Drew Adams, acm, luangruo, emacs-devel
On Tue 12 Sep 2023 at 04:30, Arthur Miller <arthur.miller@live.com> wrote:
> Perhaps elisp would be better off to accept them and make cl-defun the
> norm, instead of seing macros like define-minor-mode re-implement the
> technique and some other macro possibly do something similar which
> leads to more less maintanable code.
cl-defmacro would not help with define-minor-mode because it cannot
describe the special argument list structure in this case.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: [External] : Re: Shrinking the C core
2023-09-12 2:30 ` Arthur Miller
` (2 preceding siblings ...)
2023-09-12 19:57 ` Tomas Hlavaty
@ 2023-09-13 0:00 ` Richard Stallman
3 siblings, 0 replies; 54+ messages in thread
From: Richard Stallman @ 2023-09-13 0:00 UTC (permalink / raw)
To: Arthur Miller; +Cc: 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. ]]]
> Of course, but nobody suggests it is all-in. `length' is not a keyworded
> in CL either.
Oops, I thought it was -- but the time when I implemented and used
Common Lisp was 40 years ago.
I am pretty sure `member' used keyword arguments, and I think that
getting behavior equivalent to traditional Lisp `member' required
specifying a keyword argument. I never forgot that, during that
period, because I got reminded of it almost every day.
> But it is convenient to have keywords in
> some places, like for example in define-minor-mode or make-process, or
> even "new" define-keymap.
I would not object to using keyword arguments for functions like that
-- complex and cumbersome to use, and not used often.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Shrinking the C core
@ 2023-08-09 9:46 Eric S. Raymond
2023-08-09 12:34 ` Po Lu
0 siblings, 1 reply; 54+ messages in thread
From: Eric S. Raymond @ 2023-08-09 9:46 UTC (permalink / raw)
To: emacs-devel
Recently I have been refamiliarizing myself with the Emacs C core.
Some days ago, as a test that I understand the C core API and the
current build recipe, I made and pushed a small commit that moved
the policy code in delete-file out to Lisp, basing it on a smaller
and simpler new entry point named delete-file-internal (this is
parallel to the way delete-directory is already partitioned).
I've since been poking around the C core code and am now wondering why
there is so much C-core code that seems like it could be pushed out to
Lisp. For example, in src/fileio.c:
DEFUN ("unhandled-file-name-directory", Funhandled_file_name_directory,
Sunhandled_file_name_directory, 1, 1, 0,
doc: /* Return a directly usable directory name somehow associated with FILENAME.
A `directly usable' directory name is one that may be used without the
intervention of any file name handler.
If FILENAME is a directly usable file itself, return
\(file-name-as-directory FILENAME).
If FILENAME refers to a file which is not accessible from a local process,
then this should return nil.
The `call-process' and `start-process' functions use this function to
get a current directory to run processes in. */)
(Lisp_Object filename)
{
Lisp_Object handler;
/* If the file name has special constructs in it,
call the corresponding file name handler. */
handler = Ffind_file_name_handler (filename, Qunhandled_file_name_directory);
if (!NILP (handler))
{
Lisp_Object handled_name = call2 (handler, Qunhandled_file_name_directory,
filename);
return STRINGP (handled_name) ? handled_name : Qnil;
}
return Ffile_name_as_directory (filename);
}
Why is this in C? Is there any reason not to push it out to Lisp and
reduce the core complexity? More generally, if I do this kind of
refactor, will I be stepping on anyone's toes?
--
>>esr>>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-09 9:46 Eric S. Raymond
@ 2023-08-09 12:34 ` Po Lu
2023-08-09 15:51 ` Eric S. Raymond
0 siblings, 1 reply; 54+ messages in thread
From: Po Lu @ 2023-08-09 12:34 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: emacs-devel
"Eric S. Raymond" <esr@thyrsus.com> writes:
> Recently I have been refamiliarizing myself with the Emacs C core.
>
> Some days ago, as a test that I understand the C core API and the
> current build recipe, I made and pushed a small commit that moved
> the policy code in delete-file out to Lisp, basing it on a smaller
> and simpler new entry point named delete-file-internal (this is
> parallel to the way delete-directory is already partitioned).
>
> I've since been poking around the C core code and am now wondering why
> there is so much C-core code that seems like it could be pushed out to
> Lisp. For example, in src/fileio.c:
>
> DEFUN ("unhandled-file-name-directory", Funhandled_file_name_directory,
> Sunhandled_file_name_directory, 1, 1, 0,
> doc: /* Return a directly usable directory name somehow associated with FILENAME.
> A `directly usable' directory name is one that may be used without the
> intervention of any file name handler.
> If FILENAME is a directly usable file itself, return
> \(file-name-as-directory FILENAME).
> If FILENAME refers to a file which is not accessible from a local process,
> then this should return nil.
> The `call-process' and `start-process' functions use this function to
> get a current directory to run processes in. */)
> (Lisp_Object filename)
> {
> Lisp_Object handler;
>
> /* If the file name has special constructs in it,
> call the corresponding file name handler. */
> handler = Ffind_file_name_handler (filename, Qunhandled_file_name_directory);
> if (!NILP (handler))
> {
> Lisp_Object handled_name = call2 (handler, Qunhandled_file_name_directory,
> filename);
> return STRINGP (handled_name) ? handled_name : Qnil;
> }
>
> return Ffile_name_as_directory (filename);
> }
>
> Why is this in C? Is there any reason not to push it out to Lisp and
> reduce the core complexity?
There is a plenitude of such reasons. Whenever some code is moved to
Lisp, its structure and history is lost. Often, comments within the
extracted C code remain, but the code itself is left ajar. Bootstrap
problems are frequently introduced, as well as latent bugs. And Emacs
becomes ever so much slower.
These are not simply theoretical concerns, but problems I've encountered
many times in practice. Compounding that, fileio.c is abundant with
complex logic amended and iteratively refined over many years, which is
dangerously prone to loss or mistranscription during a refactor or a
rewrite.
Finally, this specific case is because we don't want to provide Lisp
with an easy means to bypass file name handlers. All primitives
operating on file names should thus consult file name handlers, enabling
packages like TRAMP to continue operating correctly.
> More generally, if I do this kind of refactor, will I be stepping on
> anyone's toes?
Probably. I think a better idea for a first project is this item in
etc/TODO:
** A better display of the bar cursor
Distribute a bar cursor of width > 1 evenly between the two glyphs on
each side of the bar (what to do at the edges?).
which has been on my plate for a while. I would be grateful to anyone
who decides to preempt me.
Thanks in advance!
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-09 12:34 ` Po Lu
@ 2023-08-09 15:51 ` Eric S. Raymond
2023-08-09 23:56 ` Po Lu
0 siblings, 1 reply; 54+ messages in thread
From: Eric S. Raymond @ 2023-08-09 15:51 UTC (permalink / raw)
To: Po Lu; +Cc: emacs-devel
Po Lu <luangruo@yahoo.com>:
> There is a plenitude of such reasons. Whenever some code is moved to
> Lisp, its structure and history is lost. Often, comments within the
> extracted C code remain, but the code itself is left ajar. Bootstrap
> problems are frequently introduced, as well as latent bugs. And Emacs
> becomes ever so much slower.
When I first worked on Emacs code in the 1980s Lisp was already fast
enough, and machine speeds have gone up by something like 10^3 since.
I plain don't believe the "slower" part can be an issue on modern
hardware, not even on tiny SBCs.
> Finally, this specific case is because we don't want to provide Lisp
> with an easy means to bypass file name handlers. All primitives
> operating on file names should thus consult file name handlers, enabling
> packages like TRAMP to continue operating correctly.
If calling the file-name handlers through Lisp is a crash landing,
you were already out of luck. Go have a look at delete-directory.
> Probably. I think a better idea for a first project is this item in
> etc/TODO:
This would ... not be my first project. :-)
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-09 15:51 ` Eric S. Raymond
@ 2023-08-09 23:56 ` Po Lu
2023-08-10 1:19 ` Eric S. Raymond
0 siblings, 1 reply; 54+ messages in thread
From: Po Lu @ 2023-08-09 23:56 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: emacs-devel
"Eric S. Raymond" <esr@thyrsus.com> writes:
> When I first worked on Emacs code in the 1980s Lisp was already fast
> enough, and machine speeds have gone up by something like 10^3 since.
> I plain don't believe the "slower" part can be an issue on modern
> hardware, not even on tiny SBCs.
Can you promise the same, if your changes are not restricted to one or
two functions in fileio.c, but instead pervade throughout C source?
Finally, you haven't addressed the remainder of the reasons I itemized.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-09 23:56 ` Po Lu
@ 2023-08-10 1:19 ` Eric S. Raymond
2023-08-10 11:28 ` Dmitry Gutov
0 siblings, 1 reply; 54+ messages in thread
From: Eric S. Raymond @ 2023-08-10 1:19 UTC (permalink / raw)
To: Po Lu; +Cc: emacs-devel
Po Lu <luangruo@yahoo.com>:
> "Eric S. Raymond" <esr@thyrsus.com> writes:
>
> > When I first worked on Emacs code in the 1980s Lisp was already fast
> > enough, and machine speeds have gone up by something like 10^3 since.
> > I plain don't believe the "slower" part can be an issue on modern
> > hardware, not even on tiny SBCs.
>
> Can you promise the same, if your changes are not restricted to one or
> two functions in fileio.c, but instead pervade throughout C source?
Yes, in fact, I can. Because if by some miracle we were able to
instantly rewrite the entirety of Emacs in Python (which I'm not
advocating, I chose it because it's the slowest of the major modern
scripting languages) basic considerations of clocks per second would
predict it to run a *dead minimum* of two orders of magnitude faster
than the Emacs of, say, 1990.
And 1990 Emacs was already way fast enough for the human eye and
brain, which can't even register interface lag of less than 0.17
seconds (look up the story of Jef Raskin and how he exploited this
psychophysical fact in the design of the Canon Cat sometime; it's very
instructive). The human auditory system can perceive finer timeslices,
down to about 0.02s in skilled musicians, but we're not using elisp
for audio signal processing.
If you take away nothing else from this conversation, at least get it
through your head that "more Lisp might make Emacs too slow" is a
deeply, *deeply* silly idea. It's 2023 and the only ways you can make
a user-facing program slow enough for response lag to be noticeable
are disk latency on spinning rust, network round-trips, or operations
with a superlinear big-O in critical paths. Mere interpretive overhead
won't do it.
> Finally, you haven't addressed the remainder of the reasons I itemized.
They were too obvious, describing problems that competent software
engineers know how to prevent or hedge against, and you addressed me
as though I were a n00b that just fell off a cabbage truck. My
earliest contributions to Emacs were done so long ago that they
predated the systematic Changelog convention; have you heard the
expression "teaching your grandmother to suck eggs"? My patience for
that sort of thing is limited.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-10 1:19 ` Eric S. Raymond
@ 2023-08-10 11:28 ` Dmitry Gutov
2023-08-12 2:46 ` Richard Stallman
0 siblings, 1 reply; 54+ messages in thread
From: Dmitry Gutov @ 2023-08-10 11:28 UTC (permalink / raw)
To: esr, Po Lu; +Cc: emacs-devel
On 10/08/2023 04:19, Eric S. Raymond wrote:
> basic considerations of clocks per second would
> predict it to run a*dead minimum* of two orders of magnitude faster
> than the Emacs of, say, 1990.
In addition to the examples made by others, I'll say that the sizes of
software projects have increased from 1990 as well. So if you have a
Lisp routine that simply enumerates the files in one project, it has to
do proportionally more work.
> And 1990 Emacs was already way fast enough for the human eye and
> brain, which can't even register interface lag of less than 0.17
> seconds (look up the story of Jef Raskin and how he exploited this
> psychophysical fact in the design of the Canon Cat sometime; it's very
> instructive). The human auditory system can perceive finer timeslices,
> down to about 0.02s in skilled musicians, but we're not using elisp
> for audio signal processing.
I've had to expend significant effort on many occasions to keep various
command execution times below 0.17, or 0.02, or etc.
Which is to say, while I'm very much in favor of the "lean core" concept
myself, we should accompany far-reaching changes like that with
appropriate benchmarking.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-10 11:28 ` Dmitry Gutov
@ 2023-08-12 2:46 ` Richard Stallman
2023-08-12 3:22 ` Emanuel Berg
0 siblings, 1 reply; 54+ messages in thread
From: Richard Stallman @ 2023-08-12 2:46 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: esr, luangruo, 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. ]]]
There are occasiona when it is useful, for added flexibility,
to move some function from C to Lisp. However, stability
is an important goal for Emacs, so we should not even try
to move large amounts of code to Lisp just for the sake
of moving code to Lisp.
The rate at whic we have added features already causes significant
instability.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-12 2:46 ` Richard Stallman
@ 2023-08-12 3:22 ` Emanuel Berg
2023-08-12 18:32 ` tomas
0 siblings, 1 reply; 54+ messages in thread
From: Emanuel Berg @ 2023-08-12 3:22 UTC (permalink / raw)
To: emacs-devel
Richard Stallman wrote:
> There are occasiona when it is useful, for added
> flexibility, to move some function from C to Lisp. However,
> stability is an important goal for Emacs, so we should not
> even try to move large amounts of code to Lisp just for the
> sake of moving code to Lisp.
It is just cool that Emacs is written in two languages, it is
like to continents or something connected by bridges
overlapping certain areas.
Maybe we can use SBCL to compile Elisp, and after that
integrate it into Emacs so you would be able to run all old
Elisp without changing the code, only now it would in fact be
Common Lisp implementing Elisp, i.e. the opposite of our
cl-lib (`cl-loop' etc).
Maybe some normalization efforts would have to be done to the
syntax here and there as preparatory steps ...
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-12 3:22 ` Emanuel Berg
@ 2023-08-12 18:32 ` tomas
2023-08-12 23:09 ` Emanuel Berg
0 siblings, 1 reply; 54+ messages in thread
From: tomas @ 2023-08-12 18:32 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 235 bytes --]
On Sat, Aug 12, 2023 at 05:22:45AM +0200, Emanuel Berg wrote:
> Maybe we can use SBCL to compile Elisp, and after that
> integrate it into Emacs [...]
- https://www.cliki.net/CL-Emacs
- https://xkcd.com/927/
Cheers
--
t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-12 18:32 ` tomas
@ 2023-08-12 23:09 ` Emanuel Berg
2023-08-13 5:50 ` tomas
2023-08-13 8:00 ` Andreas Schwab
0 siblings, 2 replies; 54+ messages in thread
From: Emanuel Berg @ 2023-08-12 23:09 UTC (permalink / raw)
To: emacs-devel
tomas wrote:
> https://xkcd.com/927/
HOW STANDARDS PROLIFERATE (See: A C chargers, character
encodings, instant messaging, etc.) SITUATION: There are 14
competing standards. Geek: 14?! Ridiculous! We need to
develop one universal standard that covers everyone's use
cases. Fellow Geek: Yeah! Soon: SITUATION: There are 15
competing standards. {{Title text: Fortunately, the charging
one has been solved now that we've all standardized on
mini-USB. Or is it micro-USB? Shit.}}
Okay, but here it isn't about joining the CL standard, it is
the situation that we have "the Lisp editor" yet our Lisp is
much slower than other people's Lisp, and for no good reason
what I can understand as Emacs is C, and SBCL is C. What's the
difference, why is one so much faster than the other?
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-12 23:09 ` Emanuel Berg
@ 2023-08-13 5:50 ` tomas
2023-08-13 15:54 ` [External] : " Drew Adams
2023-08-13 8:00 ` Andreas Schwab
1 sibling, 1 reply; 54+ messages in thread
From: tomas @ 2023-08-13 5:50 UTC (permalink / raw)
To: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]
On Sun, Aug 13, 2023 at 01:09:38AM +0200, Emanuel Berg wrote:
> tomas wrote:
>
> > https://xkcd.com/927/
Try a bit of lateral thinking: what if, before embarking into
a "let's do everything new, the old sucks" kind of thing those
proposing it would, at least, have a look at the attempts made
in this direction, and, you know, try to learn about why no
one of them took over the house?
This might yield a more interesting attempt.
As I see it, the main challenge for an Emacs maintainer isn't
that it is software, nor that it is a big, complex piece of
software. Rather, that its community is huge and diverse. Folks
are using it in extremely different ways (in part due to the
project's age), and moving something will break one usage dating
back to 1997 or something.
Still moving forward is a little wonder, and I'm genuinely in
awe of Eli's job (although I'm not happy about each and every
of his decisions, but I think that'll happen to everyone, due
to the situation sketched above and is thus part of it).
Cheers
--
t
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-12 23:09 ` Emanuel Berg
2023-08-13 5:50 ` tomas
@ 2023-08-13 8:00 ` Andreas Schwab
2023-08-13 9:21 ` Emanuel Berg
1 sibling, 1 reply; 54+ messages in thread
From: Andreas Schwab @ 2023-08-13 8:00 UTC (permalink / raw)
To: emacs-devel
On Aug 13 2023, Emanuel Berg wrote:
> Okay, but here it isn't about joining the CL standard, it is
> the situation that we have "the Lisp editor" yet our Lisp is
> much slower than other people's Lisp, and for no good reason
> what I can understand as Emacs is C, and SBCL is C.
But SBCL is not portable.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-13 8:00 ` Andreas Schwab
@ 2023-08-13 9:21 ` Emanuel Berg
2023-08-14 7:27 ` Alfred M. Szmidt
0 siblings, 1 reply; 54+ messages in thread
From: Emanuel Berg @ 2023-08-13 9:21 UTC (permalink / raw)
To: emacs-devel
Andreas Schwab wrote:
>> Okay, but here it isn't about joining the CL standard, it
>> is the situation that we have "the Lisp editor" yet our
>> Lisp is much slower than other people's Lisp, and for no
>> good reason what I can understand as Emacs is C, and SBCL
>> is C.
>
> But SBCL is not portable.
Step one would be to identify why SBCL is so much faster.
Say it is faster for reasons A, B, C and D. Surely A, B, C and
D are not all unportable features, so one would first try add
the same thing to the Elisp model.
If that fails maybe one would consider ECL or some other
faster, yet portable solution ...
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-13 9:21 ` Emanuel Berg
@ 2023-08-14 7:27 ` Alfred M. Szmidt
2023-08-14 7:36 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Alfred M. Szmidt @ 2023-08-14 7:27 UTC (permalink / raw)
To: Emanuel Berg; +Cc: emacs-devel
Step one would be to identify why SBCL is so much faster.
The short reason why SBCL is faster is that SBCL uses lots of type
checking and interference, which allows it to figure out optimizations
better. And then using assembly to implement such optimizations. CL
code compiled without DECLARE/DECLAIM is generally slow, but can be
made fast if you are very careful, and lucky that the things you need
are implemented as VOPs -- which are entierly unportable.
It also has the luxury of using a language that is set more or less in
stone, that doesn't change constantly. Which means the developers can
spend quite a bit more time on optimizing what they have.
If that fails maybe one would consider ECL or some other
faster, yet portable solution ...
"Porting" Emacs to CL is not just slap ECL or some CL implementation
on top. Adding type checking of the sort that SBCL does, would be
possible but ALOT of work. It would most definitly require a entierly
new VM, and with that comes dragons.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-14 7:27 ` Alfred M. Szmidt
@ 2023-08-14 7:36 ` Ihor Radchenko
2023-08-14 7:50 ` Alfred M. Szmidt
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-14 7:36 UTC (permalink / raw)
To: Alfred M. Szmidt, Andrea Corallo; +Cc: Emanuel Berg, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> Step one would be to identify why SBCL is so much faster.
>
> The short reason why SBCL is faster is that SBCL uses lots of type
> checking and interference, which allows it to figure out optimizations
> better. And then using assembly to implement such optimizations. CL
> code compiled without DECLARE/DECLAIM is generally slow, but can be
> made fast if you are very careful, and lucky that the things you need
> are implemented as VOPs -- which are entierly unportable.
AFAIK, Elisp is full of type checks (all these BUFFERP/CHECK_STRING in
C code). Also, AFAIR, native-comp is making use of some of the type
checks as well, allowing some extra optimizations.
So, there might be some room for improvement after all.
Do you have some references detailing what SBCL does?
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-14 7:36 ` Ihor Radchenko
@ 2023-08-14 7:50 ` Alfred M. Szmidt
2023-08-15 22:57 ` Emanuel Berg
0 siblings, 1 reply; 54+ messages in thread
From: Alfred M. Szmidt @ 2023-08-14 7:50 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: akrl, incal, emacs-devel
AFAIK, Elisp is full of type checks (all these BUFFERP/CHECK_STRING in
C code). Also, AFAIR, native-comp is making use of some of the type
checks as well, allowing some extra optimizations.
SBCL does far more detailed checks than that. Which is why it makes
it very unportable, since the base case is trivial, but the optimized
one is not. Check for example FLOOR in sbcl/src/code/numbers.lisp ,
and compare it to FLOOR in Emacs Lisp.
SBCL has many luxuries that Emacs does not have.
So, there might be some room for improvement after all.
There is always a door for that ... but someone needs to open it.
Do you have some references detailing what SBCL does?
http://www.sbcl.org/sbcl-internals/ and the source code.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-14 7:50 ` Alfred M. Szmidt
@ 2023-08-15 22:57 ` Emanuel Berg
2023-08-16 10:27 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Emanuel Berg @ 2023-08-15 22:57 UTC (permalink / raw)
To: emacs-devel
Alfred M. Szmidt wrote:
> one is not. Check for example FLOOR in
> sbcl/src/code/numbers.lisp , and compare it to FLOOR in
> Emacs Lisp.
Are we talking `floor' as in (floor 3.1415) ; 3 ?
How do we make a benchmark for that? Run it 1000+ times for
random floats? But maybe SBCL has faster random as well!
Actually, even I have a better random than Elisp:
https://dataswamp.org/~incal/emacs-init/random-urandom/
It is more random than `random', using the Linux random.
But I didn't compare them in terms of speed. It is a so called
dynamic module, that is, not built-in but still written in C.
Anyway, I'd be happy to add something `floor' to the
benchmarks, for sure!
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-15 22:57 ` Emanuel Berg
@ 2023-08-16 10:27 ` Ihor Radchenko
2023-08-19 13:29 ` Emanuel Berg
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-16 10:27 UTC (permalink / raw)
To: Emanuel Berg; +Cc: emacs-devel
Emanuel Berg <incal@dataswamp.org> writes:
> Are we talking `floor' as in (floor 3.1415) ; 3 ?
>
> How do we make a benchmark for that? Run it 1000+ times for
> random floats? But maybe SBCL has faster random as well!
You can generate random number sequence first, excluding it from the
benchmark, and then benchmark mapping #'floor on the already generated
sequence. Ideally, use the same sequence for both Elisp and SBCL.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-16 10:27 ` Ihor Radchenko
@ 2023-08-19 13:29 ` Emanuel Berg
2023-08-20 5:09 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Emanuel Berg @ 2023-08-19 13:29 UTC (permalink / raw)
To: emacs-devel
Ihor Radchenko wrote:
>> Are we talking `floor' as in (floor 3.1415) ; 3 ?
>>
>> How do we make a benchmark for that? Run it 1000+ times for
>> random floats? But maybe SBCL has faster random as well!
>
> You can generate random number sequence first, excluding it
> from the benchmark, and then benchmark mapping #'floor on
> the already generated sequence. Ideally, use the same
> sequence for both Elisp and SBCL.
You are right, good idea. But maybe it is already known why
floor is slower in Elisp than SBCL?
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-19 13:29 ` Emanuel Berg
@ 2023-08-20 5:09 ` Ihor Radchenko
2023-08-20 6:51 ` Emanuel Berg
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-20 5:09 UTC (permalink / raw)
To: Emanuel Berg; +Cc: emacs-devel
Emanuel Berg <incal@dataswamp.org> writes:
>> You can generate random number sequence first, excluding it
>> from the benchmark, and then benchmark mapping #'floor on
>> the already generated sequence. Ideally, use the same
>> sequence for both Elisp and SBCL.
>
> You are right, good idea. But maybe it is already known why
> floor is slower in Elisp than SBCL?
The discussion about floor started from Alfred using `floor' as an
example where CL uses system-dependent optimizations and thus being much
faster. https://yhetil.org/emacs-devel/E1qVSLD-00079S-Gg@fencepost.gnu.org/
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 5:09 ` Ihor Radchenko
@ 2023-08-20 6:51 ` Emanuel Berg
2023-08-20 7:14 ` Ihor Radchenko
2023-08-20 21:51 ` Drew Adams
0 siblings, 2 replies; 54+ messages in thread
From: Emanuel Berg @ 2023-08-20 6:51 UTC (permalink / raw)
To: emacs-devel
Ihor Radchenko wrote:
>>> You can generate random number sequence first, excluding
>>> it from the benchmark, and then benchmark mapping #'floor
>>> on the already generated sequence. Ideally, use the same
>>> sequence for both Elisp and SBCL.
>>
>> You are right, good idea. But maybe it is already known why
>> floor is slower in Elisp than SBCL?
>
> The discussion about floor started from Alfred using `floor'
> as an example where CL uses system-dependent optimizations
> and thus being much faster.
So the answer to the question, Why is SBCL faster?
is "optimizations". And the answer to the question, Why don't
we have those optimizations? is "they are not portable"?
But isn't that what we do already with compilation and in
particular native compilation, why can't that add
optimizations for the native system?
Some commands/Elisp on that (compilation and native
compilation) as a side note, maybe someone finds them
entertaining:
https://dataswamp.org/~incal/conf/.zsh/install-emacs
https://dataswamp.org/~incal/emacs-init/native.el
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 6:51 ` Emanuel Berg
@ 2023-08-20 7:14 ` Ihor Radchenko
2023-08-20 8:28 ` Alfred M. Szmidt
2023-08-20 21:51 ` Drew Adams
1 sibling, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-20 7:14 UTC (permalink / raw)
To: Emanuel Berg, Alfred M. Szmidt; +Cc: emacs-devel
Emanuel Berg <incal@dataswamp.org> writes:
>> The discussion about floor started from Alfred using `floor'
>> as an example where CL uses system-dependent optimizations
>> and thus being much faster.
>
> So the answer to the question, Why is SBCL faster?
> is "optimizations". And the answer to the question, Why don't
> we have those optimizations? is "they are not portable"?
Looking at
https://github.com/sbcl/sbcl/blob/master/src/code/numbers.lisp#L390,
they employ certain x86-64-, x86-, ppc64-specific optimizations.
Althrough, Elisp's rounding_driver is not too bad actually. It also does
shortcuts depending on the argument type.
AFAIU, the main difference in SBCL vs. Elisp is that Elisp type checks
are often called repetitively on the same values. Even though the checks
are rather fast (typecheck is usually just a single xor + equal
operation), repetitive calls do add up.
And even this is not a definitive answer. I do not think that we can
point out a single reason why SBCL is faster. I am not even sure if SBCL
is _always_ faster.
> But isn't that what we do already with compilation and in
> particular native compilation, why can't that add
> optimizations for the native system?
If we talk about type checking, Elisp uses dynamic typing and
compilation cannot do much about it. Native compilation also does not
touch C subroutines - the place where typechecks are performed.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 7:14 ` Ihor Radchenko
@ 2023-08-20 8:28 ` Alfred M. Szmidt
2023-08-20 9:29 ` Emanuel Berg
0 siblings, 1 reply; 54+ messages in thread
From: Alfred M. Szmidt @ 2023-08-20 8:28 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: incal, emacs-devel
And even this is not a definitive answer. I do not think that we can
point out a single reason why SBCL is faster. I am not even sure if SBCL
is _always_ faster.
Always faster than what? What are you comparing? SBCL is a compiler,
Emacs is more than that.
It should be quite obvious why SBCL is faster than the Emacs Lisp VM
(or even native). Just look at this call to (car "foo"), and compare
what happens in Emacs.
* (disassemble 'foo)
; disassembly for FOO
; Size: 166 bytes. Origin: #x225D873F ; FOO
; 3F: 488B042590060020 MOV RAX, [#x20000690]
; 47: 488945F8 MOV [RBP-8], RAX
; 4B: 48892C2560060020 MOV [#x20000660], RBP
; 53: 488B142518000020 MOV RDX, [#x20000018]
; 5B: 488D4210 LEA RAX, [RDX+16]
; 5F: 483B042520000020 CMP RAX, [#x20000020]
; 67: 7770 JA L2
; 69: 4889042518000020 MOV [#x20000018], RAX
; 71: L0: 488B0570FFFFFF MOV RAX, [RIP-144] ; "foo"
; 78: 488902 MOV [RDX], RAX
; 7B: 48C7420817010020 MOV QWORD PTR [RDX+8], #x20000117 ; NIL
; 83: 80CA07 OR DL, 7
; 86: 48312C2560060020 XOR [#x20000660], RBP
; 8E: 7402 JEQ L1
; 90: CC09 INT3 9 ; pending interrupt trap
; 92: L1: 4C8D4424F0 LEA R8, [RSP-16]
; 97: 4883EC30 SUB RSP, 48
; 9B: BFAF0B1520 MOV EDI, #x20150BAF ; 'LIST
; A0: 488B3551FFFFFF MOV RSI, [RIP-175] ; '(VALUES
; (SIMPLE-ARRAY ..))
; A7: 488B0552FFFFFF MOV RAX, [RIP-174] ; '("foo")
; AE: 498940F0 MOV [R8-16], RAX
; B2: 488B054FFFFFFF MOV RAX, [RIP-177] ; "(CAR \"foo\")"
; B9: 498940E8 MOV [R8-24], RAX
; BD: 49C740E017010020 MOV QWORD PTR [R8-32], #x20000117 ; NIL
; C5: B90C000000 MOV ECX, 12
; CA: 498928 MOV [R8], RBP
; CD: 498BE8 MOV RBP, R8
; D0: B882B12620 MOV EAX, #x2026B182 ; #<FDEFN SB-C::%COMPILE-TIME-TYPE-ERROR>
; D5: FFD0 CALL RAX
; D7: CC10 INT3 16 ; Invalid argument count trap
; D9: L2: 6A10 PUSH 16
; DB: FF1425B0080020 CALL [#x200008B0] ; #x21A00540: LIST-ALLOC-TRAMP
; E2: 5A POP RDX
; E3: EB8C JMP L0
NIL
*
> But isn't that what we do already with compilation and in
> particular native compilation, why can't that add
> optimizations for the native system?
If we talk about type checking, Elisp uses dynamic typing and
compilation cannot do much about it. Native compilation also does not
touch C subroutines - the place where typechecks are performed.
SBCL implements a Lisp, Lisp by definition is dynamically typed.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 8:28 ` Alfred M. Szmidt
@ 2023-08-20 9:29 ` Emanuel Berg
2023-08-20 15:22 ` Alfred M. Szmidt
0 siblings, 1 reply; 54+ messages in thread
From: Emanuel Berg @ 2023-08-20 9:29 UTC (permalink / raw)
To: emacs-devel
Alfred M. Szmidt wrote:
> And even this is not a definitive answer. I do not think
> that we can point out a single reason why SBCL is faster.
> I am not even sure if SBCL is _always_ faster.
>
> Always faster than what? What are you comparing?
We are working on it.
> SBCL is a compiler, Emacs is more than that.
Including SBCL with SLIME, but that would still be CL with
SBCL and not Elisp which is what we are (not) comparing with.
> It should be quite obvious why SBCL is faster than the Emacs
> Lisp VM (or even native). Just look at this call to (car
> "foo"), and compare what happens in Emacs.
>
> * (disassemble 'foo)
> ; disassembly for FOO
> ; Size: 166 bytes. Origin: #x225D873F ; FOO
> ; 3F: 488B042590060020 MOV RAX, [#x20000690]
> ; 47: 488945F8 MOV [RBP-8], RAX
> ; 4B: 48892C2560060020 MOV [#x20000660], RBP
> ; 53: 488B142518000020 MOV RDX, [#x20000018]
> ; 5B: 488D4210 LEA RAX, [RDX+16]
> ; 5F: 483B042520000020 CMP RAX, [#x20000020]
> ; 67: 7770 JA L2
> ; 69: 4889042518000020 MOV [#x20000018], RAX
> ; 71: L0: 488B0570FFFFFF MOV RAX, [RIP-144] ; "foo"
> ; 78: 488902 MOV [RDX], RAX
> ; 7B: 48C7420817010020 MOV QWORD PTR [RDX+8], #x20000117 ; NIL
> ; 83: 80CA07 OR DL, 7
> ; 86: 48312C2560060020 XOR [#x20000660], RBP
> ; 8E: 7402 JEQ L1
> ; 90: CC09 INT3 9 ; pending interrupt trap
> ; 92: L1: 4C8D4424F0 LEA R8, [RSP-16]
> ; 97: 4883EC30 SUB RSP, 48
> ; 9B: BFAF0B1520 MOV EDI, #x20150BAF ; 'LIST
> ; A0: 488B3551FFFFFF MOV RSI, [RIP-175] ; '(VALUES
> ; (SIMPLE-ARRAY ..))
> ; A7: 488B0552FFFFFF MOV RAX, [RIP-174] ; '("foo")
> ; AE: 498940F0 MOV [R8-16], RAX
> ; B2: 488B054FFFFFFF MOV RAX, [RIP-177] ; "(CAR \"foo\")"
> ; B9: 498940E8 MOV [R8-24], RAX
> ; BD: 49C740E017010020 MOV QWORD PTR [R8-32], #x20000117 ; NIL
> ; C5: B90C000000 MOV ECX, 12
> ; CA: 498928 MOV [R8], RBP
> ; CD: 498BE8 MOV RBP, R8
> ; D0: B882B12620 MOV EAX, #x2026B182 ; #<FDEFN SB-C::%COMPILE-TIME-TYPE-ERROR>
> ; D5: FFD0 CALL RAX
> ; D7: CC10 INT3 16 ; Invalid argument count trap
> ; D9: L2: 6A10 PUSH 16
> ; DB: FF1425B0080020 CALL [#x200008B0] ; #x21A00540: LIST-ALLOC-TRAMP
> ; E2: 5A POP RDX
> ; E3: EB8C JMP L0
> NIL
> *
Okay?
>> If we talk about type checking, Elisp uses dynamic typing
>> and compilation cannot do much about it. Native compilation
>> also does not touch C subroutines - the place where
>> typechecks are performed.
>
> SBCL implements a Lisp, Lisp by definition is
> dynamically typed.
Only for the kind of use (code) that we are used to. See this:
https://medium.com/@MartinCracauer/static-type-checking-in-the-programmable-programming-language-lisp-79bb79eb068a
For example
(defunt meh5c ((int p1) (int p2))
(+ p1 p2))
(meh5c 1 2) ; ==> 3
with defunt being a macro that uses declare.
A simple example is given earlier in the text,
(defun meh (p1)
(declare (fixnum p1))
(+ p1 3))
--
underground experts united
https://dataswamp.org/~incal
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 9:29 ` Emanuel Berg
@ 2023-08-20 15:22 ` Alfred M. Szmidt
2023-08-20 15:36 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Alfred M. Szmidt @ 2023-08-20 15:22 UTC (permalink / raw)
To: Emanuel Berg; +Cc: emacs-devel
Please keep the CC intact, not everyone subscribed.
> It should be quite obvious why SBCL is faster than the Emacs
> Lisp VM (or even native). Just look at this call to (car
> "foo"), and compare what happens in Emacs.
>
> * (disassemble 'foo)
> ; disassembly for FOO
> ; Size: 166 bytes. Origin: #x225D873F ; FOO
> ; 3F: 488B042590060020 MOV RAX, [#x20000690]
> ; 47: 488945F8 MOV [RBP-8], RAX
> ; 4B: 48892C2560060020 MOV [#x20000660], RBP
> ; 53: 488B142518000020 MOV RDX, [#x20000018]
> ; 5B: 488D4210 LEA RAX, [RDX+16]
> ; 5F: 483B042520000020 CMP RAX, [#x20000020]
> ; 67: 7770 JA L2
> ; 69: 4889042518000020 MOV [#x20000018], RAX
> ; 71: L0: 488B0570FFFFFF MOV RAX, [RIP-144] ; "foo"
> ; 78: 488902 MOV [RDX], RAX
> ; 7B: 48C7420817010020 MOV QWORD PTR [RDX+8], #x20000117 ; NIL
> ; 83: 80CA07 OR DL, 7
> ; 86: 48312C2560060020 XOR [#x20000660], RBP
> ; 8E: 7402 JEQ L1
> ; 90: CC09 INT3 9 ; pending interrupt trap
> ; 92: L1: 4C8D4424F0 LEA R8, [RSP-16]
> ; 97: 4883EC30 SUB RSP, 48
> ; 9B: BFAF0B1520 MOV EDI, #x20150BAF ; 'LIST
> ; A0: 488B3551FFFFFF MOV RSI, [RIP-175] ; '(VALUES
> ; (SIMPLE-ARRAY ..))
> ; A7: 488B0552FFFFFF MOV RAX, [RIP-174] ; '("foo")
> ; AE: 498940F0 MOV [R8-16], RAX
> ; B2: 488B054FFFFFFF MOV RAX, [RIP-177] ; "(CAR \"foo\")"
> ; B9: 498940E8 MOV [R8-24], RAX
> ; BD: 49C740E017010020 MOV QWORD PTR [R8-32], #x20000117 ; NIL
> ; C5: B90C000000 MOV ECX, 12
> ; CA: 498928 MOV [R8], RBP
> ; CD: 498BE8 MOV RBP, R8
> ; D0: B882B12620 MOV EAX, #x2026B182 ; #<FDEFN SB-C::%COMPILE-TIME-TYPE-ERROR>
> ; D5: FFD0 CALL RAX
> ; D7: CC10 INT3 16 ; Invalid argument count trap
> ; D9: L2: 6A10 PUSH 16
> ; DB: FF1425B0080020 CALL [#x200008B0] ; #x21A00540: LIST-ALLOC-TRAMP
> ; E2: 5A POP RDX
> ; E3: EB8C JMP L0
> NIL
> *
Okay?
I guess that you do not understand the above? Or what? Do you know
and understand what happens in Emacs when a similar call is done? It
is far more than "166 bytes".
>> If we talk about type checking, Elisp uses dynamic typing
>> and compilation cannot do much about it. Native compilation
>> also does not touch C subroutines - the place where
>> typechecks are performed.
>
> SBCL implements a Lisp, Lisp by definition is
> dynamically typed.
Only for the kind of use (code) that we are used to. See this:
https://medium.com/@MartinCracauer/static-type-checking-in-the-programmable-programming-language-lisp-79bb79eb068a
This has literally nothing to do with the difference between static
typing, and dynamic typing. The author, and you, have it completeley
backwards to the point where I need to suggest that you take sometime
to read up on basic Lisp compilers, and then look into very good Lisp
compilers (CMUCL and SBCL come to mind). Since it is already showing
that it is very hard to even explain basic Lisp compiler behaviour
without going to fundamentals.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 15:22 ` Alfred M. Szmidt
@ 2023-08-20 15:36 ` Ihor Radchenko
2023-08-20 15:45 ` Eli Zaretskii
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-20 15:36 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: Emanuel Berg, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> Please keep the CC intact, not everyone subscribed.
>
> > It should be quite obvious why SBCL is faster than the Emacs
> > Lisp VM (or even native). Just look at this call to (car
> > "foo"), and compare what happens in Emacs.
> >
> > * (disassemble 'foo)
> > ; disassembly for FOO
> > ; Size: 166 bytes. Origin: #x225D873F ; FOO
>> ...
> Okay?
>
> I guess that you do not understand the above? Or what? Do you know
> and understand what happens in Emacs when a similar call is done? It
> is far more than "166 bytes".
It would be helpful if you show us what happens in Elisp with a similar
call. Especially after native compilation.
I am asking genuinely because `car' (1) has dedicated opt code and thus
should be one of the best-optimized function calls on Elisp side; (2)
Fcar is nothing but
/* Take the car or cdr of something whose type is not known. */
INLINE Lisp_Object
CAR (Lisp_Object c)
{
if (CONSP (c))
return XCAR (c); // <- XCONS (c)->u.s.car
if (!NILP (c))
wrong_type_argument (Qlistp, c);
return Qnil;
}
So, it is a very simple example that can actually explain the basic
differences between Elisp and CL. It would be nice if you (considering
your low-level understanding) can provide us with an analysis of what is
different between Elisp and CL implementations of such a simple
function.
> This has literally nothing to do with the difference between static
> typing, and dynamic typing. The author, and you, have it completeley
> backwards ...
I am sorry, because it was my message that started the confusion.
I was mostly referring to separation between Elisp
interpreted/byte/native code and C subrs. AFAIU, static analysis info
cannot be passed between these two parts of Emacs runtime: subr cannot
know in advance what Lisp_Object type it is working on, even if static
analysis of the caller Elisp code has such information (e.g. from GCC
JIT compiler).
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 15:36 ` Ihor Radchenko
@ 2023-08-20 15:45 ` Eli Zaretskii
2023-08-20 15:54 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Eli Zaretskii @ 2023-08-20 15:45 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: ams, incal, emacs-devel
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Emanuel Berg <incal@dataswamp.org>, emacs-devel@gnu.org
> Date: Sun, 20 Aug 2023 15:36:34 +0000
>
> "Alfred M. Szmidt" <ams@gnu.org> writes:
>
> > I guess that you do not understand the above? Or what? Do you know
> > and understand what happens in Emacs when a similar call is done? It
> > is far more than "166 bytes".
>
> It would be helpful if you show us what happens in Elisp with a similar
> call.
See below.
> Especially after native compilation.
Native compilation doesn't affect 'car', because it's a primitive.
> I am asking genuinely because `car' (1) has dedicated opt code and thus
> should be one of the best-optimized function calls on Elisp side; (2)
> Fcar is nothing but
>
> /* Take the car or cdr of something whose type is not known. */
> INLINE Lisp_Object
> CAR (Lisp_Object c)
> {
> if (CONSP (c))
> return XCAR (c); // <- XCONS (c)->u.s.car
> if (!NILP (c))
> wrong_type_argument (Qlistp, c);
> return Qnil;
> }
It's very easy to see the code of 'car' in Emacs. All you need is run
GDB:
$ gdb ./emacs
...
(gdb) disassemble /m Fcar
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 15:45 ` Eli Zaretskii
@ 2023-08-20 15:54 ` Ihor Radchenko
2023-08-20 16:29 ` Alfred M. Szmidt
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-20 15:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, incal, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> It would be helpful if you show us what happens in Elisp with a similar
>> call.
>
> See below.
Sorry, I was not clear. I was asking to help comparing between
disassembly of Elisp and CL versions. I myself is not familiar with
assembly code.
> It's very easy to see the code of 'car' in Emacs. All you need is run
> GDB:
>
> $ gdb ./emacs
> ...
> (gdb) disassemble /m Fcar
So, while I can do this mechanically, it will not understand it.
Not to the level to draw conclusions about what is different in Elisp
compared to CL.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 15:54 ` Ihor Radchenko
@ 2023-08-20 16:29 ` Alfred M. Szmidt
2023-08-20 16:37 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Alfred M. Szmidt @ 2023-08-20 16:29 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: eliz, incal, emacs-devel
> It's very easy to see the code of 'car' in Emacs. All you need is run
> GDB:
>
> $ gdb ./emacs
> ...
> (gdb) disassemble /m Fcar
So, while I can do this mechanically, it will not understand it.
Not to the level to draw conclusions about what is different in Elisp
compared to CL.
The issue is not Emacs Lisp vs. Common Lisp. What you mean is what
the difference is between SBCL and GNU Emacs.'
The question can be rephrased as what is the difference between GNU
Emacs and GCC? Why is GCC so much faster? And if you phrase it like
that you will see that it really doesn't make much sense anymore,
since you are comparing different things.
Emacs could implement optimizaations that GCC does for C, or ADA
.. but it breaks down very quickly.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 16:29 ` Alfred M. Szmidt
@ 2023-08-20 16:37 ` Ihor Radchenko
2023-08-20 17:19 ` Alfred M. Szmidt
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-20 16:37 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: eliz, incal, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> The issue is not Emacs Lisp vs. Common Lisp. What you mean is what
> the difference is between SBCL and GNU Emacs.'
>
> The question can be rephrased as what is the difference between GNU
> Emacs and GCC? Why is GCC so much faster? And if you phrase it like
> that you will see that it really doesn't make much sense anymore,
> since you are comparing different things.
> Emacs could implement optimizaations that GCC does for C, or ADA
> .. but it breaks down very quickly.
Not really. Native compilation already uses GCC. At least on the byte
code instructions and, separately, in subr code.
There is more than just GCC vs byte code VM in it.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 16:37 ` Ihor Radchenko
@ 2023-08-20 17:19 ` Alfred M. Szmidt
2023-08-20 17:31 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Alfred M. Szmidt @ 2023-08-20 17:19 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: eliz, incal, emacs-devel
> The issue is not Emacs Lisp vs. Common Lisp. What you mean is what
> the difference is between SBCL and GNU Emacs.'
>
> The question can be rephrased as what is the difference between GNU
> Emacs and GCC? Why is GCC so much faster? And if you phrase it like
> that you will see that it really doesn't make much sense anymore,
> since you are comparing different things.
> Emacs could implement optimizaations that GCC does for C, or ADA
> .. but it breaks down very quickly.
Not really. Native compilation already uses GCC. At least on the byte
code instructions and, separately, in subr code.
There is more than just GCC vs byte code VM in it.
It is not about native compilation! It is about what OPTIMIZATIONS
can be done to the actual code flow. Just using GCC doesn't do ANY
optimizations to how the Lisp code is optimized or how its flow is
changed due to optimizations!
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 17:19 ` Alfred M. Szmidt
@ 2023-08-20 17:31 ` Ihor Radchenko
2023-08-20 18:54 ` Alfred M. Szmidt
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-20 17:31 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: eliz, incal, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> Not really. Native compilation already uses GCC. At least on the byte
> code instructions and, separately, in subr code.
> There is more than just GCC vs byte code VM in it.
>
> It is not about native compilation! It is about what OPTIMIZATIONS
> can be done to the actual code flow. Just using GCC doesn't do ANY
> optimizations to how the Lisp code is optimized or how its flow is
> changed due to optimizations!
Then, what does GCC do? AFAIK, GCC JIT takes the Elisp byte code,
transforms it into JIT pseudocode, and optimizes the actual code flow.
For example, when I write
(when (> x y) (when (> x y) x))
I expect GCC JIT to throw away the duplicate comparison.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 17:31 ` Ihor Radchenko
@ 2023-08-20 18:54 ` Alfred M. Szmidt
2023-08-20 19:15 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Alfred M. Szmidt @ 2023-08-20 18:54 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: eliz, incal, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> Not really. Native compilation already uses GCC. At least on the byte
> code instructions and, separately, in subr code.
> There is more than just GCC vs byte code VM in it.
>
> It is not about native compilation! It is about what OPTIMIZATIONS
> can be done to the actual code flow. Just using GCC doesn't do ANY
> optimizations to how the Lisp code is optimized or how its flow is
> changed due to optimizations!
Then, what does GCC do? AFAIK, GCC JIT takes the Elisp byte code,
transforms it into JIT pseudocode, and optimizes the actual code flow.
What does GCC do _WHERE_? What backend? What language? You're
speaking in such broad terms that it makes it impossible to continue
this discussion. I don't know how the native compilation works, but
no matter what you feed to GCC it cannot do magic and any optimization
should be done on what the Emacs compiler does.
For example, when I write
(when (> x y) (when (> x y) x))
I expect GCC JIT to throw away the duplicate comparison.
Why do you expect that? Why do you think it is duplicate? Where are
the guarantees that > or WHEN don't have side-effects? Do you know
the exact type of X and Y so you can skip a cascade of type checks to
pick the right comparison operator? Can you use fixnum comparison of
a specific bit width? Do you need to use bignum comparison?
That is the type of information SBCL knows about, or allows the user
to specify. Emacs does not have that today, and that incures one set
of overhead. There are plenty more...
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 18:54 ` Alfred M. Szmidt
@ 2023-08-20 19:15 ` Ihor Radchenko
2023-08-20 19:24 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-20 19:15 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: eliz, incal, emacs-devel
"Alfred M. Szmidt" <ams@gnu.org> writes:
> Then, what does GCC do? AFAIK, GCC JIT takes the Elisp byte code,
> transforms it into JIT pseudocode, and optimizes the actual code flow.
>
> What does GCC do _WHERE_? What backend? What language? You're
> speaking in such broad terms that it makes it impossible to continue
> this discussion. I don't know how the native compilation works, but
> no matter what you feed to GCC it cannot do magic and any optimization
> should be done on what the Emacs compiler does.
Native compilation provides the necessary information about Elisp to GCC.
Otherwise, native compilation would be useless.
You may check out the details in
https://zenodo.org/record/3736363 and
https://toobnix.org/w/1f997b3c-00dc-4f7d-b2ce-74538c194fa7
> For example, when I write
>
> (when (> x y) (when (> x y) x))
>
> I expect GCC JIT to throw away the duplicate comparison.
>
> Why do you expect that? Why do you think it is duplicate? Where are
> the guarantees that > or WHEN don't have side-effects? Do you know
> the exact type of X and Y so you can skip a cascade of type checks to
> pick the right comparison operator? Can you use fixnum comparison of
> a specific bit width? Do you need to use bignum comparison?
At least some of these questions are answered by the code on Emacs side.
Native compiler transforms the Elisp byte code, using its knowledge
about function purity, types, and maybe other things, into LIMP that can
be fed to GCC JIT. Then, GCC JIT uses the provided info to do actual
optimization.
> That is the type of information SBCL knows about, or allows the user
> to specify. Emacs does not have that today, and that incures one set
> of overhead. There are plenty more...
AFAIK, users cannot specify type info manually, but types are tracked
when transforming Elisp byte code into LIMP representation.
The only problem (AFAIU) is that GCC JIT cannot reach inside subr level,
so all these information does not benefit Emacs functions implemented in
C.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 19:15 ` Ihor Radchenko
@ 2023-08-20 19:24 ` Ihor Radchenko
2023-08-21 2:33 ` Eli Zaretskii
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-20 19:24 UTC (permalink / raw)
To: Alfred M. Szmidt; +Cc: eliz, incal, emacs-devel
Ihor Radchenko <yantar92@posteo.net> writes:
> The only problem (AFAIU) is that GCC JIT cannot reach inside subr level,
> so all these information does not benefit Emacs functions implemented in
> C.
If I am right here, it might actually be worth it to rewrite some of the
subroutines into Elisp. For example rounding_driver (called by
`floor') code is full of runtime type checks:
CHECK_NUMBER (n);
if (NILP (d))
...
CHECK_NUMBER (d);
...
if (FIXNUMP (d))
if (XFIXNUM (d) == 0)
...
if (FIXNUMP (n))
...
else if (FLOATP (d))
if (XFLOAT_DATA (d) == 0)
int nscale = FLOATP (n) ? double_integer_scale (XFLOAT_DATA (n)) : 0;
..
During native compilation, if type information and n and d is available,
GCC might have a chance to cut a number of branches away from the above
code.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-20 19:24 ` Ihor Radchenko
@ 2023-08-21 2:33 ` Eli Zaretskii
2023-08-21 4:11 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Eli Zaretskii @ 2023-08-21 2:33 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: ams, incal, emacs-devel
> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: eliz@gnu.org, incal@dataswamp.org, emacs-devel@gnu.org
> Date: Sun, 20 Aug 2023 19:24:36 +0000
>
> If I am right here, it might actually be worth it to rewrite some of the
> subroutines into Elisp. For example rounding_driver (called by
> `floor') code is full of runtime type checks:
>
> CHECK_NUMBER (n);
> if (NILP (d))
> ...
> CHECK_NUMBER (d);
> ...
> if (FIXNUMP (d))
> if (XFIXNUM (d) == 0)
> ...
> if (FIXNUMP (n))
> ...
> else if (FLOATP (d))
> if (XFLOAT_DATA (d) == 0)
> int nscale = FLOATP (n) ? double_integer_scale (XFLOAT_DATA (n)) : 0;
> ..
>
> During native compilation, if type information and n and d is available,
> GCC might have a chance to cut a number of branches away from the above
> code.
Cut them how? AFAICT, none of the tests above are redundant.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-21 2:33 ` Eli Zaretskii
@ 2023-08-21 4:11 ` Ihor Radchenko
2023-08-21 4:15 ` Po Lu
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-21 4:11 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: ams, incal, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> CHECK_NUMBER (n);
>> if (NILP (d))
>> return FLOATP (n) ? double_to_integer (double_round (XFLOAT_DATA (n))) : n;
>> ...
>> During native compilation, if type information and n and d is available,
>> GCC might have a chance to cut a number of branches away from the above
>> code.
>
> Cut them how? AFAICT, none of the tests above are redundant.
Consider the following:
(let ((a 10))
(setq a (+ a 100))
(floor a nil))
During compilation of the above code, the compiler will know that a is a
positive integer. Therefore, CHECK_NUMBER, NILP, and FLOATP are not
necessary and can be omitted in the call to `floor':
(let ((a 10))
(setq a (+ a 100))
a)
However, GCC JIT has no information about the internal structure of the
`floor' subr. Hence, it is currently unable to perform such
optimization.
It could, if it were somehow given an information about `floor'
implementation.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-21 4:11 ` Ihor Radchenko
@ 2023-08-21 4:15 ` Po Lu
2023-08-21 4:36 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Po Lu @ 2023-08-21 4:15 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Eli Zaretskii, ams, incal, emacs-devel
Ihor Radchenko <yantar92@posteo.net> writes:
> (let ((a 10))
> (setq a (+ a 100))
> (floor a nil))
>
> During compilation of the above code, the compiler will know that a is a
> positive integer. Therefore, CHECK_NUMBER, NILP, and FLOATP are not
> necessary and can be omitted in the call to `floor':
>
> (let ((a 10))
> (setq a (+ a 100))
> a)
>
> However, GCC JIT has no information about the internal structure of the
> `floor' subr. Hence, it is currently unable to perform such
> optimization.
>
> It could, if it were somehow given an information about `floor'
> implementation.
This should thus be implemented in the native compiler, without
affecting the code of Ffloor itself.
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-21 4:15 ` Po Lu
@ 2023-08-21 4:36 ` Ihor Radchenko
2023-08-21 4:43 ` Po Lu
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-21 4:36 UTC (permalink / raw)
To: Po Lu; +Cc: Eli Zaretskii, ams, incal, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
>> However, GCC JIT has no information about the internal structure of the
>> `floor' subr. Hence, it is currently unable to perform such
>> optimization.
>>
>> It could, if it were somehow given an information about `floor'
>> implementation.
>
> This should thus be implemented in the native compiler, without
> affecting the code of Ffloor itself.
I do understand that the approach you propose is indeed used, for
example, for `car' in emit_lval_XCAR. However, is it practical for
functions like `floor'?
`car' implementation is very unlikely to change in future. But `floor'
and other functions (we should not be limited to `floor') may change
their implementations. The extra "native comp" copy of the
implementation will need to be always synchronized with the original
implementation. I doubt that it is practical maintenance-wise.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-21 4:36 ` Ihor Radchenko
@ 2023-08-21 4:43 ` Po Lu
2023-08-21 5:06 ` Ihor Radchenko
0 siblings, 1 reply; 54+ messages in thread
From: Po Lu @ 2023-08-21 4:43 UTC (permalink / raw)
To: Ihor Radchenko; +Cc: Eli Zaretskii, ams, incal, emacs-devel
Ihor Radchenko <yantar92@posteo.net> writes:
> I do understand that the approach you propose is indeed used, for
> example, for `car' in emit_lval_XCAR. However, is it practical for
> functions like `floor'?
>
> `car' implementation is very unlikely to change in future.
Why not?
> But `floor' and other functions (we should not be limited to `floor')
> may change their implementations. The extra "native comp" copy of the
> implementation will need to be always synchronized with the original
> implementation. I doubt that it is practical maintenance-wise.
How and why so? How are Fcar and Ffloor divergent in this department?
^ permalink raw reply [flat|nested] 54+ messages in thread
* Re: Shrinking the C core
2023-08-21 4:43 ` Po Lu
@ 2023-08-21 5:06 ` Ihor Radchenko
2023-08-21 5:25 ` [External] : " Drew Adams
0 siblings, 1 reply; 54+ messages in thread
From: Ihor Radchenko @ 2023-08-21 5:06 UTC (permalink / raw)
To: Po Lu; +Cc: Eli Zaretskii, ams, incal, emacs-devel
Po Lu <luangruo@yahoo.com> writes:
>> `car' implementation is very unlikely to change in future.
>
> Why not?
Mostly because such basic functions are rarely changed.
Of course, it is not impossible that `car' is changed in future.
>> But `floor' and other functions (we should not be limited to `floor')
>> may change their implementations. The extra "native comp" copy of the
>> implementation will need to be always synchronized with the original
>> implementation. I doubt that it is practical maintenance-wise.
>
> How and why so? How are Fcar and Ffloor divergent in this department?
`floor' might also be rather stable. I was mostly referring to "we
should not be limited to `floor'" - it may be a problem for other
functions.
But let me rephrase it in other terms: what you propose will require
maintaining two separate implementations of subroutines - one in C, and
one specially tailored to GCC JIT psudocode. This may be doable for a
small set of core primitives, but not scalable if we want to make more
subroutines benefit from GGC JIT optimizations.
Another idea, if rewriting in Elisp is not feasible, could be somehow
structuring the internal C code in such a way that we can derive GCC
JIT pseudocode right from the C function bodies.
For example, Ffloor could be (1) split into smaller functions dedicated
to certain argument type combinations; (2) record a metadata readable by
native comp code about which small function correspond to different
argument types. Then, native comp can emit direct calls to these smaller
(and faster) functions when the type is known.
--
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
^ permalink raw reply [flat|nested] 54+ messages in thread
* RE: [External] : Re: Shrinking the C core
2023-08-20 6:51 ` Emanuel Berg
2023-08-20 7:14 ` Ihor Radchenko
@ 2023-08-20 21:51 ` Drew Adams
1 sibling, 0 replies; 54+ messages in thread
From: Drew Adams @ 2023-08-20 21:51 UTC (permalink / raw)
To: Emanuel Berg, emacs-devel@gnu.org
> > The discussion about floor started from Alfred using `floor'
> > as an example where CL uses system-dependent optimizations
> > and thus being much faster.
>
> So the answer to the question, Why is SBCL faster?
> is "optimizations". And the answer to the question, Why don't
> we have those optimizations? is "they are not portable"?
https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node103.html#SECTION001300000000000000000
Common Lisp is a standard. Different implementations
of it should respect the standard, but the standard
allows for different behaviors to some extent, esp.
wrt performance. CL has multiple ways of declaring
different levels of optimization, which a given
implementation can support or not.
Particular optimizations are not expected to be
portable.
^ permalink raw reply [flat|nested] 54+ messages in thread
end of thread, other threads:[~2023-10-21 8:22 UTC | newest]
Thread overview: 54+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-13 11:20 Shrinking the C core Gerd Möllmann
2023-08-13 12:52 ` Ihor Radchenko
2023-08-13 15:53 ` [External] : " Drew Adams
2023-08-14 2:25 ` Emanuel Berg
-- strict thread matches above, loose matches on Subject: below --
2023-09-13 5:24 Arthur Miller
2023-09-15 8:18 ` Emanuel Berg
2023-09-17 0:46 ` Richard Stallman
2023-09-17 4:55 ` Alfred M. Szmidt
2023-09-17 9:13 ` Emanuel Berg
2023-09-17 9:54 ` Alfred M. Szmidt
2023-09-17 17:38 ` Drew Adams
2023-09-18 19:38 ` Emanuel Berg
2023-09-19 10:19 ` Richard Stallman
2023-09-19 10:21 ` Richard Stallman
2023-09-19 11:21 ` Emanuel Berg
2023-09-19 12:39 ` Eli Zaretskii
2023-09-21 20:27 ` Richard Stallman
2023-09-17 5:41 ` Eli Zaretskii
2023-09-17 8:54 ` Emanuel Berg
2023-09-17 17:29 ` Drew Adams
2023-09-18 19:40 ` Emanuel Berg
2023-10-15 1:53 ` Richard Stallman
2023-10-15 2:46 ` Emanuel Berg
2023-10-15 5:57 ` Eli Zaretskii
2023-10-15 5:54 ` Eli Zaretskii
2023-10-17 4:51 ` Emanuel Berg
2023-10-20 7:48 ` Arsen Arsenović
2023-10-20 10:08 ` Alfred M. Szmidt
2023-10-21 8:22 ` Emanuel Berg
2023-08-27 15:14 Arthur Miller
2023-08-28 1:41 ` Po Lu
2023-08-28 4:53 ` Arthur Miller
2023-08-28 5:36 ` Po Lu
2023-08-28 6:55 ` Arthur Miller
2023-08-28 7:31 ` Po Lu
2023-08-28 14:08 ` Arthur Miller
2023-08-31 2:07 ` Richard Stallman
2023-09-06 0:58 ` Richard Stallman
2023-09-06 5:04 ` Arthur Miller
2023-09-06 11:29 ` Alan Mackenzie
2023-09-08 2:00 ` Arthur Miller
2023-09-08 15:38 ` [External] : " Drew Adams
2023-09-09 11:55 ` Arthur Miller
2023-09-09 12:55 ` Eli Zaretskii
2023-09-09 13:20 ` Arthur Miller
2023-09-10 0:09 ` Drew Adams
2023-09-11 0:40 ` Richard Stallman
2023-09-11 15:10 ` João Távora
2023-09-11 16:12 ` Drew Adams
2023-09-11 20:37 ` Tomas Hlavaty
2023-09-11 21:10 ` João Távora
2023-09-12 19:52 ` Tomas Hlavaty
2023-09-12 20:52 ` João Távora
2023-09-15 8:43 ` Emanuel Berg
2023-09-11 21:09 ` Eric S. Raymond
2023-09-12 2:05 ` Arthur Miller
2023-09-12 4:38 ` Gerd Möllmann
2023-09-12 5:48 ` Arthur Miller
2023-09-12 2:30 ` Arthur Miller
2023-09-12 12:15 ` Emanuel Berg
2023-09-12 12:32 ` Emanuel Berg
2023-09-12 19:57 ` Tomas Hlavaty
2023-09-13 0:00 ` Richard Stallman
2023-08-09 9:46 Eric S. Raymond
2023-08-09 12:34 ` Po Lu
2023-08-09 15:51 ` Eric S. Raymond
2023-08-09 23:56 ` Po Lu
2023-08-10 1:19 ` Eric S. Raymond
2023-08-10 11:28 ` Dmitry Gutov
2023-08-12 2:46 ` Richard Stallman
2023-08-12 3:22 ` Emanuel Berg
2023-08-12 18:32 ` tomas
2023-08-12 23:09 ` Emanuel Berg
2023-08-13 5:50 ` tomas
2023-08-13 15:54 ` [External] : " Drew Adams
2023-08-13 8:00 ` Andreas Schwab
2023-08-13 9:21 ` Emanuel Berg
2023-08-14 7:27 ` Alfred M. Szmidt
2023-08-14 7:36 ` Ihor Radchenko
2023-08-14 7:50 ` Alfred M. Szmidt
2023-08-15 22:57 ` Emanuel Berg
2023-08-16 10:27 ` Ihor Radchenko
2023-08-19 13:29 ` Emanuel Berg
2023-08-20 5:09 ` Ihor Radchenko
2023-08-20 6:51 ` Emanuel Berg
2023-08-20 7:14 ` Ihor Radchenko
2023-08-20 8:28 ` Alfred M. Szmidt
2023-08-20 9:29 ` Emanuel Berg
2023-08-20 15:22 ` Alfred M. Szmidt
2023-08-20 15:36 ` Ihor Radchenko
2023-08-20 15:45 ` Eli Zaretskii
2023-08-20 15:54 ` Ihor Radchenko
2023-08-20 16:29 ` Alfred M. Szmidt
2023-08-20 16:37 ` Ihor Radchenko
2023-08-20 17:19 ` Alfred M. Szmidt
2023-08-20 17:31 ` Ihor Radchenko
2023-08-20 18:54 ` Alfred M. Szmidt
2023-08-20 19:15 ` Ihor Radchenko
2023-08-20 19:24 ` Ihor Radchenko
2023-08-21 2:33 ` Eli Zaretskii
2023-08-21 4:11 ` Ihor Radchenko
2023-08-21 4:15 ` Po Lu
2023-08-21 4:36 ` Ihor Radchenko
2023-08-21 4:43 ` Po Lu
2023-08-21 5:06 ` Ihor Radchenko
2023-08-21 5:25 ` [External] : " Drew Adams
2023-08-20 21:51 ` Drew Adams
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).