Re: Shrinking the C core

Re: Shrinking the C core

[Gerd Möllmann]

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

Re: Shrinking the C core

[Ihor Radchenko]

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.

RE: [External] : Re: Shrinking the C core

[Drew Adams]

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

RE: [External] : Re: Shrinking the C core

[Drew Adams]

> 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 [one] of his decisions, but I think
> that'll happen to everyone...

+1.

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

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

RE: [External] : Re: Shrinking the C core

[Drew Adams]

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

RE: [External] : Re: Shrinking the C core

[Drew Adams]

> Mostly because such basic functions are rarely changed.
> Of course, it is not impossible that `car' is changed in future.

Perhaps it will become "electric"...

RE: [External] : Re: Shrinking the C core

[Drew Adams]

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

Re: [External] : Re: Shrinking the C core

[Arthur Miller]

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

Re: [External] : Re: Shrinking the C core

[Eli Zaretskii]

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

Re: [External] : Re: Shrinking the C core

[Arthur Miller]

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.

RE: [External] : Re: Shrinking the C core

[Drew Adams]

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

Re: [External] : Re: Shrinking the C core

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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)

Re: [External] : Re: Shrinking the C core

[João Távora]

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

RE: [External] : Re: Shrinking the C core

[Drew Adams]

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.

Re: [External] : Re: Shrinking the C core

[Tomas Hlavaty]

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)

Re: [External] : Re: Shrinking the C core

[Eric S. Raymond]

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>

Re: [External] : Re: Shrinking the C core

[João Távora]

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

Re: [External] : Re: Shrinking the C core

[Arthur Miller]

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

Re: [External] : Re: Shrinking the C core

[Arthur Miller]

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.

Re: [External] : Re: Shrinking the C core

[Gerd Möllmann]

"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 :-).

Re: [External] : Re: Shrinking the C core

[Arthur Miller]

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.

Re: [External] : Re: Shrinking the C core

[Eli Zaretskii]

[Redirected to emacs-tangents]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Richard Stallman <rms@gnu.org>,  Drew Adams <drew.adams@oracle.com>,
>  arthur.miller@live.com,  acm@muc.de,  luangruo@yahoo.com,
>  emacs-devel@gnu.org
> Date: Tue, 12 Sep 2023 06:38:00 +0200
> 
> "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.

Right.  And the display code.  And text en/decoding.  And input queue.
And faces.  Etc. etc. -- these are all written in C, but are full of
Lisp data structures and calls into Lisp, so separating them is
anything but easy or even straightforward.

People who have enough talents, knowledge, and energy to do this kind
of job will be better off, and will serve the community better, if
they design an Emacs differently, taking into consideration the main
lessons we've learned.  That "neo-Emacs" could have a mode whereby it
worked in a way compatible with the current Emacs, so that people who
must run the old applications could run them without changes.  But it
should be based on different, more modern architectural decisions.
Handling of buffer text, GC, the display engine, threads -- all these
and more needs to be rethought and preferably replaced with more
modern solutions, to avoid bumping into the same limitations right
from the get-go.

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

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

Re: [External] : Re: Shrinking the C core

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> [Redirected to emacs-tangents]
>
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Richard Stallman <rms@gnu.org>,  Drew Adams <drew.adams@oracle.com>,
>>  arthur.miller@live.com,  acm@muc.de,  luangruo@yahoo.com,
>>  emacs-devel@gnu.org
>> Date: Tue, 12 Sep 2023 06:38:00 +0200
>> 
>> "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.
>
> Right.  And the display code.  And text en/decoding.  And input queue.
> And faces.  Etc. etc. -- these are all written in C, but are full of
> Lisp data structures and calls into Lisp, so separating them is
> anything but easy or even straightforward.

Which are all components that have grown immensely in both volume and
complexity over the past 20 years or so, which is to say, since you
(Eric) last expended significant amounts of time developing Emacs.  Not
a single individual understands everything, particularly not to the
extent necessary to orchestrate a rewrite or re-implementation.

> People who have enough talents, knowledge, and energy to do this kind
> of job will be better off

So it is already a stretch to assume that such people will materialize
at all.

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

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

Re: [External] : Re: Shrinking the C core

[Tomas Hlavaty]

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.

Re: [External] : Re: Shrinking the C core

[Tomas Hlavaty]

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.

Re: [External] : Re: Shrinking the C core

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

> [Redirected to emacs-tangents]
>
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Richard Stallman <rms@gnu.org>,  Drew Adams <drew.adams@oracle.com>,
>>  arthur.miller@live.com,  acm@muc.de,  luangruo@yahoo.com,
>>  emacs-devel@gnu.org
>> Date: Tue, 12 Sep 2023 06:38:00 +0200
>> 
>> "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.
>
> Right.  And the display code.  And text en/decoding.  And input queue.
> And faces.  Etc. etc. -- these are all written in C, but are full of
> Lisp data structures and calls into Lisp, so separating them is
> anything but easy or even straightforward.
>
> People who have enough talents, knowledge, and energy to do this kind
> of job will be better off, and will serve the community better, if
> they design an Emacs differently, taking into consideration the main
> lessons we've learned.

I don't know what you have learned, but I have learned that Guy Steel
was correct when he told the world back in 1998 already: don't really on
a few people for the development, instead make things extensible by
the users. In an applicaiton that is almost a life style for many users
and where most of users are developers as well it makes sense to use the
same implementation and extension language, because it removes a barrier
for design and experimentation. For web developers it might make sense
to write their tools in JS, for Lisp developers it make sense to use
Lisp for their tools. That would make for more sustainable development.

> lessons we've learned.  That "neo-Emacs" could have a mode whereby it
> worked in a way compatible with the current Emacs, so that people who
> must run the old applications could run them without changes.  But it

Such a "mode" would still require you to implement al that stuff you
have now, there is no way around, and I am quite sure you know it.

Also; there is nothing that says that you can't have different
implementation under the hood. There is so much narrow-mindedness and
assumptions from you. Instead of assuming bunch of what I think or don't
think, as you always do, why don't you just ask me? I didn't answered
further in our private correspondence because of your constant assuming
what I think or don't think and so on. Ask me instead; if I haven't think
of something, or thought wrong, I'll be glad to learn about it.

> should be based on different, more modern architectural decisions.
> Handling of buffer text, GC, the display engine, threads -- all these
> and more needs to be rethought and preferably replaced with more
> modern solutions, to avoid bumping into the same limitations right
> from the get-go.

Yes, and what in your opinion *is* a suggestion to completely remove the
C code, which actually was a very relevant in a thread about shrinking
the C core? Also, to answer all those who can't put 1 + 1 togther by
themselves: I have suggested to remove completely C core in a thread
about shrinking the C core. I think a "maximal shrink" of C core is
quite on topic :-).

About your "neo-design", just implementing the editor in a Lisp machine
instead of having a Lisp machine in the editor is itself already a
radical design change. Not to mention that the Lisp machine suggested
already has threading and some other tools that would make life much
easier so you could concentrate on actually improving the editor instead
of the Lisp machine. Look at other similar applications already doing it
in that "clumsy" CL; Lem already has several rendering backends. How
many do you have?

Nobody says that you have to implement stuff under the hood the same
way; I have said we need C core and elisp semantics implemented in
CL. It is laborous but possible. Under the hood it could be implemented
with any changes needed, and in the future design could be exchanged for
something else, complemented etc.

Anyway, your rhetorics give allusion that Emacs is dead, users should go
to greener pastures you who want something more modern dead suites their
needs. I don't know, but those are vibes I get from your arguments.

Anyone can *already* use other "more modern applications". Reason users
don't use Hemlock or Climax or don't rush to Lem (perhaps they should)
is, as we have already discussed in private and Reddit, because they
can't run Emacs packages in them. People don't want Emacs-like editor,
they want GNU Emacs. Which is good, and which you are aware of from both
private discussion and Reddit. Sure, loosing *some* applications is OK,
there is a natural regression too, some things are not maintained or get
irrelevant for other reasons, but not all.

Another thing is your way to talk to people and keep this community; I
was told I am a lazy idiot who came here to beg someone to write
something for me, and I am told to watch my mouth when I answered. Great
community you are maintaining, thank you for that.

Re: [External] : Re: Shrinking the C core

[João Távora]

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

Re: [External] : Re: Shrinking the C core

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

Re: [External] : Re: Shrinking the C core

[Arthur Miller]

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

Re: [External] : Re: Shrinking the C core

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>   esr@thyrsus.com,
>   rms@gnu.org,  drew.adams@oracle.com,  acm@muc.de,  luangruo@yahoo.com,
>   emacs-tangents@gnu.org
> Date: Tue, 12 Sep 2023 21:58:43 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > [Redirected to emacs-tangents]
> >
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: Richard Stallman <rms@gnu.org>,  Drew Adams <drew.adams@oracle.com>,
> >>  arthur.miller@live.com,  acm@muc.de,  luangruo@yahoo.com,
> >>  emacs-devel@gnu.org
> >> Date: Tue, 12 Sep 2023 06:38:00 +0200
> >> 
> >> "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.
> >
> > Right.  And the display code.  And text en/decoding.  And input queue.
> > And faces.  Etc. etc. -- these are all written in C, but are full of
> > Lisp data structures and calls into Lisp, so separating them is
> > anything but easy or even straightforward.
> >
> > People who have enough talents, knowledge, and energy to do this kind
> > of job will be better off, and will serve the community better, if
> > they design an Emacs differently, taking into consideration the main
> > lessons we've learned.
> 
> I don't know what you have learned, but I have learned that Guy Steel
> was correct when he told the world back in 1998 already: don't really on
> a few people for the development, instead make things extensible by
> the users. In an applicaiton that is almost a life style for many users
> and where most of users are developers as well it makes sense to use the
> same implementation and extension language, because it removes a barrier
> for design and experimentation. For web developers it might make sense
> to write their tools in JS, for Lisp developers it make sense to use
> Lisp for their tools. That would make for more sustainable development.
> 
> > lessons we've learned.  That "neo-Emacs" could have a mode whereby it
> > worked in a way compatible with the current Emacs, so that people who
> > must run the old applications could run them without changes.  But it
> 
> Such a "mode" would still require you to implement al that stuff you
> have now, there is no way around, and I am quite sure you know it.
> 
> Also; there is nothing that says that you can't have different
> implementation under the hood. There is so much narrow-mindedness and
> assumptions from you. Instead of assuming bunch of what I think or don't
> think, as you always do, why don't you just ask me? I didn't answered
> further in our private correspondence because of your constant assuming
> what I think or don't think and so on. Ask me instead; if I haven't think
> of something, or thought wrong, I'll be glad to learn about it.
> 
> > should be based on different, more modern architectural decisions.
> > Handling of buffer text, GC, the display engine, threads -- all these
> > and more needs to be rethought and preferably replaced with more
> > modern solutions, to avoid bumping into the same limitations right
> > from the get-go.
> 
> Yes, and what in your opinion *is* a suggestion to completely remove the
> C code, which actually was a very relevant in a thread about shrinking
> the C core? Also, to answer all those who can't put 1 + 1 togther by
> themselves: I have suggested to remove completely C core in a thread
> about shrinking the C core. I think a "maximal shrink" of C core is
> quite on topic :-).
> 
> About your "neo-design", just implementing the editor in a Lisp machine
> instead of having a Lisp machine in the editor is itself already a
> radical design change. Not to mention that the Lisp machine suggested
> already has threading and some other tools that would make life much
> easier so you could concentrate on actually improving the editor instead
> of the Lisp machine. Look at other similar applications already doing it
> in that "clumsy" CL; Lem already has several rendering backends. How
> many do you have?
> 
> Nobody says that you have to implement stuff under the hood the same
> way; I have said we need C core and elisp semantics implemented in
> CL. It is laborous but possible. Under the hood it could be implemented
> with any changes needed, and in the future design could be exchanged for
> something else, complemented etc.
> 
> Anyway, your rhetorics give allusion that Emacs is dead, users should go
> to greener pastures you who want something more modern dead suites their
> needs. I don't know, but those are vibes I get from your arguments.
> 
> Anyone can *already* use other "more modern applications". Reason users
> don't use Hemlock or Climax or don't rush to Lem (perhaps they should)
> is, as we have already discussed in private and Reddit, because they
> can't run Emacs packages in them. People don't want Emacs-like editor,
> they want GNU Emacs. Which is good, and which you are aware of from both
> private discussion and Reddit. Sure, loosing *some* applications is OK,
> there is a natural regression too, some things are not maintained or get
> irrelevant for other reasons, but not all.

I don't know how to respond to this tirade, nor even where did it came
from and what did I do to deserve such rudeness.

I expressed my opinions on what would be a worthwhile "rewrite" of
Emacs.  Feel free to disagree with what I said, but why do you have to
mention my alleged "narrow-mindedness", or accuse me in making some
assumptions about what you think, or claim that I think Emacs is dead?
What I wrote was about Emacs and its future, not about you.  And no, I
don't think Emacs is dead, or I wouldn't be wasting my free time on
this job.

> Another thing is your way to talk to people and keep this community; I
> was told I am a lazy idiot who came here to beg someone to write
> something for me, and I am told to watch my mouth when I answered. Great
> community you are maintaining, thank you for that.

You are mistaken: I don't maintain this community.  I can barely tell
people to use kinder words, and even then they don't always listen.

RE: [External] : Re: Shrinking the C core

[Drew Adams]

[Moving reply to e-tangents.]

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

+1.

Except maybe for the "not used often".  Depends on the
"often" use.  If used often without any keyword args (or
optional args, for that matter), what difference does it
make that the function _has_ keyword/optional args?  By
definition and convention, such args are generally not
for the most common (the default) use case.

But the general point, I think, is that keyword (and
optional) args turn one function into a family of several,
and that can be useful.  But the "base" function, called without such args, can be just as convenient as if there
were no such args possible.

Re: [External] : Re: Shrinking the C core

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>>   esr@thyrsus.com,
>>   rms@gnu.org,  drew.adams@oracle.com,  acm@muc.de,  luangruo@yahoo.com,
>>   emacs-tangents@gnu.org
>> Date: Tue, 12 Sep 2023 21:58:43 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > [Redirected to emacs-tangents]
>> >
>> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> >> Cc: Richard Stallman <rms@gnu.org>,  Drew Adams <drew.adams@oracle.com>,
>> >>  arthur.miller@live.com,  acm@muc.de,  luangruo@yahoo.com,
>> >>  emacs-devel@gnu.org
>> >> Date: Tue, 12 Sep 2023 06:38:00 +0200
>> >> 
>> >> "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.
>> >
>> > Right.  And the display code.  And text en/decoding.  And input queue.
>> > And faces.  Etc. etc. -- these are all written in C, but are full of
>> > Lisp data structures and calls into Lisp, so separating them is
>> > anything but easy or even straightforward.
>> >
>> > People who have enough talents, knowledge, and energy to do this kind
>> > of job will be better off, and will serve the community better, if
>> > they design an Emacs differently, taking into consideration the main
>> > lessons we've learned.
>> 
>> I don't know what you have learned, but I have learned that Guy Steel
>> was correct when he told the world back in 1998 already: don't really on
>> a few people for the development, instead make things extensible by
>> the users. In an applicaiton that is almost a life style for many users
>> and where most of users are developers as well it makes sense to use the
>> same implementation and extension language, because it removes a barrier
>> for design and experimentation. For web developers it might make sense
>> to write their tools in JS, for Lisp developers it make sense to use
>> Lisp for their tools. That would make for more sustainable development.
>> 
>> > lessons we've learned.  That "neo-Emacs" could have a mode whereby it
>> > worked in a way compatible with the current Emacs, so that people who
>> > must run the old applications could run them without changes.  But it
>> 
>> Such a "mode" would still require you to implement al that stuff you
>> have now, there is no way around, and I am quite sure you know it.
>> 
>> Also; there is nothing that says that you can't have different
>> implementation under the hood. There is so much narrow-mindedness and
>> assumptions from you. Instead of assuming bunch of what I think or don't
>> think, as you always do, why don't you just ask me? I didn't answered
>> further in our private correspondence because of your constant assuming
>> what I think or don't think and so on. Ask me instead; if I haven't think
>> of something, or thought wrong, I'll be glad to learn about it.
>> 
>> > should be based on different, more modern architectural decisions.
>> > Handling of buffer text, GC, the display engine, threads -- all these
>> > and more needs to be rethought and preferably replaced with more
>> > modern solutions, to avoid bumping into the same limitations right
>> > from the get-go.
>> 
>> Yes, and what in your opinion *is* a suggestion to completely remove the
>> C code, which actually was a very relevant in a thread about shrinking
>> the C core? Also, to answer all those who can't put 1 + 1 togther by
>> themselves: I have suggested to remove completely C core in a thread
>> about shrinking the C core. I think a "maximal shrink" of C core is
>> quite on topic :-).
>> 
>> About your "neo-design", just implementing the editor in a Lisp machine
>> instead of having a Lisp machine in the editor is itself already a
>> radical design change. Not to mention that the Lisp machine suggested
>> already has threading and some other tools that would make life much
>> easier so you could concentrate on actually improving the editor instead
>> of the Lisp machine. Look at other similar applications already doing it
>> in that "clumsy" CL; Lem already has several rendering backends. How
>> many do you have?
>> 
>> Nobody says that you have to implement stuff under the hood the same
>> way; I have said we need C core and elisp semantics implemented in
>> CL. It is laborous but possible. Under the hood it could be implemented
>> with any changes needed, and in the future design could be exchanged for
>> something else, complemented etc.
>> 
>> Anyway, your rhetorics give allusion that Emacs is dead, users should go
>> to greener pastures you who want something more modern dead suites their
>> needs. I don't know, but those are vibes I get from your arguments.
>> 
>> Anyone can *already* use other "more modern applications". Reason users
>> don't use Hemlock or Climax or don't rush to Lem (perhaps they should)
>> is, as we have already discussed in private and Reddit, because they
>> can't run Emacs packages in them. People don't want Emacs-like editor,
>> they want GNU Emacs. Which is good, and which you are aware of from both
>> private discussion and Reddit. Sure, loosing *some* applications is OK,
>> there is a natural regression too, some things are not maintained or get
>> irrelevant for other reasons, but not all.
>
> I don't know how to respond to this tirade, nor even where did it came
> from and what did I do to deserve such rudeness.

Sory if it came out as a tirade, it answer on the mail before, your
thoughts in that mail, and also me complaining about some persons taking
very much freedom in how they talk to or about me, and when answered
back I am threatened to be blocked from here. It perhaps should have
been three mails instead of one, sorry if it is too diffused or
confused, it was the intention to be rude to you.

> I expressed my opinions on what would be a worthwhile "rewrite" of
> Emacs.  Feel free to disagree with what I said, but why do you have to
> mention my alleged "narrow-mindedness", or accuse me in making some
> assumptions about what you think, or claim that I think Emacs is dead?
> What I wrote was about Emacs and its future, not about you.  And no, I
> don't think Emacs is dead, or I wouldn't be wasting my free time on
> this job.
>
>> Another thing is your way to talk to people and keep this community; I
>> was told I am a lazy idiot who came here to beg someone to write
>> something for me, and I am told to watch my mouth when I answered. Great
>> community you are maintaining, thank you for that.
>
> You are mistaken: I don't maintain this community.  I can barely tell
> people to use kinder words, and even then they don't always listen.

Well you can; but you didn't.

I am forced to change the mailing list while other people are not, and I
am told to "dropp of" and "watch my mouth or risk to be blocked (I
believe what he meant)" while called "for lazy idiot" becaue of bringing
up what someone found uncomfortable to talk about, and I don't see that
person being threaten the way I am; and I am not able to bring that up,
than I guess I am not welcome here.

Re: [External] : Re: Shrinking the C core

[Arthur Miller]

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

> [Moving reply to e-tangents.]
>
>> > 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.
>
> +1.
>
> Except maybe for the "not used often".  Depends on the
> "often" use.  If used often without any keyword args (or
> optional args, for that matter), what difference does it
> make that the function _has_ keyword/optional args?  By
> definition and convention, such args are generally not
> for the most common (the default) use case.

Well yes, of course, it is corect. I think it depends on what "not often
used" referred to. I interepretted it as not often used argument, not
the function itself. Those more often used but possible to omit are of
course usually optional and in front of the optional list, but those
that are used in some more specialized circumstance or by very few are
perhaps good candidates for keyword arguments? I don't know, that is how
I perecieve it.

> But the general point, I think, is that keyword (and
> optional) args turn one function into a family of several,
> and that can be useful.  But the "base" function, called without such args, can be just as convenient as if there
> were no such args possible.

Yes indeed; and I agree with what you wrote in your longer second mail
about that. They do lessen the need for more functions which means less
API surface to document and potentially lookup and learn. Isn't a good
example that window functions that I wanted to make into same once in
the context of help/info patch? I don't remember which it were tbh
:). Something with selecting window on just current frame or all frames
or something like that.

Re: [External] : Re: Shrinking the C core

[Po Lu]

Arthur Miller <arthur.miller@live.com> writes:

> Sory if it came out as a tirade, it answer on the mail before, your
> thoughts in that mail, and also me complaining about some persons taking
> very much freedom in how they talk to or about me, and when answered
> back I am threatened to be blocked from here. It perhaps should have
> been three mails instead of one, sorry if it is too diffused or
> confused,

No one ever threatened to block you from the list.

> it was the intention to be rude to you.

[...]

> I am forced to change the mailing list while other people are not, and I
> am told to "dropp of" and "watch my mouth or risk to be blocked (I
> believe what he meant)" while called "for lazy idiot" becaue of bringing
> up what someone found uncomfortable to talk about, and I don't see that
> person being threaten the way I am; and I am not able to bring that up,
> than I guess I am not welcome here.

Au contraire, everyone has been asked to transfer this thread to
emacs-tangents, not only you.  The important detail being that others
have long since grown weary of said thread, electing to direct their
attention to things more worthwhile instead.

Additionally, you were never labeled a ``lazy idiot'', and furthermore
never threatened with ``blocking''.

Would you please dispense with the self-victimizing?  If anything, the
only persistently aggressive participant has been you, perpetually
vituperating against your interlocutors with accusations of censorship
and sectarianism whilst demonstrating precisely those traits that you
claim to reject.

With that said, feel free to continue posting long diatribes advocating
rewrites of Emacs in Common Lisp, now that the thread has been moved off
emacs-devel.  But please remove me from the carbon copy list, and mind
that talking never does anything in Emacs: it never did, and it never
will.

TIA.

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

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

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

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

RE: [External] : Re: Shrinking the C core

[Drew Adams]

(Again, moving to emacs-tangents@gnu.org.)

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

Not necessarily.  It depends - on context, how
often each combination is used, and even user
preferences.

With 10 different functions, instead of one,
to represent a "family" of functions, users
can wonder "Which should I use?".  The problem
introduced then is finding good function names
and specifying, in the doc of each (or in some
"family" doc) just what the differences are,
and how they can (or can't) be used together.

IOW, it can make sense to use a "family" name
and keywords, with a single explanation of the
keywords, together.  A single explanation lets
you address what combinations make sense etc.

Happily, if keywords are at least available
(possible) in the language, you have a choice
of which approach to use.  Nothing _requires_
you to define a function with keyword args,
instead of defining separate functions (up to
N-factorial of them!).

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

Arthur Miller wrote:

> Yes indeed; and I agree with what you wrote in your longer
> second mail about that. They do lessen the need for more
> functions which means less API surface to document and
> potentially lookup and learn. Isn't a good example that
> window functions that I wanted to make into same once in the
> context of help/info patch? I don't remember which it were
> tbh :). Something with selecting window on just current
> frame or all frames or something like that.

I think, in general and ranked from best to worse,

1. Many functions, all with few arguments
2. One function with not-that-many optional arguments
3. One function with keyword arguments
4. One function with too many optional arguments

Documentation is not a problem for case 1 since small
functions with clear names and few arguments typically
requires just 1~3 lines of documentation.

This documentation is also easy to browse, you won't have to
navigate the help buffer or search it for what an argument or
keyword does, written far below somewhere in the text.

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: Shrinking the C core

[Drew Adams]

> I think, in general and ranked from best to worse,
> 
> 1. Many functions, all with few arguments
> 2. One function with not-that-many optional arguments
> 3. One function with keyword arguments
> 4. One function with too many optional arguments

I don't think any such generalization is
very helpful - regardless of how one might
choose to order those.

> Documentation is not a problem for case 1 since small
> functions with clear names and few arguments typically
> requires just 1~3 lines of documentation.
> 
> This documentation is also easy to browse, you won't have to
> navigate the help buffer or search it for what an argument or
> keyword does, written far below somewhere in the text.

I think you're missing the point I made about
a "family" of functions.

Just having separate "many functions, all with
few arguments" can make it more difficult to
understand which is which, what's what, and
when to use this one or that one.

More generally, it's harder to see what the
familial relations are.  You can't as easily
see the forest because of all the trees.

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

Drew Adams wrote:

> I think you're missing the point I made about a "family"
> of functions.
>
> Just having separate "many functions, all with few
> arguments" can make it more difficult to understand which is
> which, what's what, and when to use this one or that one.
>
> More generally, it's harder to see what the familial
> relations are. You can't as easily see the forest because of
> all the trees.

Indeed, you have to be familiar with the functions in order to
use them. Just as you have to be familiar with the optional
arguments and keywords to use them. So there is no difference
in that regard.

But I think the functions are easier to see than arguments and
keywords which are inside functions, because when I use
functions, I'm myself outside, not inside of them.

Or put it like this: If I have a computer that can do 100
things, I prefer 100 functions to 2 functions, one with
50 optional arguments and the other with 50 keywords.

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: Shrinking the C core

[Drew Adams]

> > I think you're missing the point I made about a "family"
> > of functions.
> >
> > Just having separate "many functions, all with few
> > arguments" can make it more difficult to understand which is
> > which, what's what, and when to use this one or that one.
> >
> > More generally, it's harder to see what the familial
> > relations are. You can't as easily see the forest because of
> > all the trees.
> 
> Indeed, you have to be familiar with the functions in order to
> use them. Just as you have to be familiar with the optional
> arguments and keywords to use them. So there is no difference
> in that regard.

There is a difference.  The doc of for the family,
i.e., all the variants of the function, is in one
place.  And that doc can, and typically does,
describe them together, i.e., it describes their
relationships.

And another, obvious, difference, for things like
apropos search and completion of commands.

> But I think the functions are easier to see than arguments and
> keywords which are inside functions, because when I use
> functions, I'm myself outside, not inside of them.

"The functions" can't be "easier to see" than the
single function, which encompasses the family.

Of course, you haven't made clear what you mean
by "to see" or your being "outside"/"inside"
functions.  So maybe you have some unsaid meanings
that fit your "easier to see" characterization.
 
> Or put it like this: If I have a computer that can do 100
> things, I prefer 100 functions to 2 functions, one with
> 50 optional arguments and the other with 50 keywords.

There's no need to exaggerate or deal with such
a level of abstraction.  The ability to have
&optional, &rest, and keyword arguments doesn't
prevent anyone from not making use of any of those
and instead defining 8000 separate functions (to
further the exaggeration).

Do you use &optional?  &rest?  Why, since you
apparently have a blanket rule that using
multiple separate functions is always better.

Re: [External] : Re: Shrinking the C core

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

Re: [External] : Re: Shrinking the C core

[Alfred M. Szmidt]

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

Re: [External] : Re: Shrinking the C core

[Eli Zaretskii]

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

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

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

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

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

Re: [External] : Re: Shrinking the C core

[Alfred M. Szmidt]

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.

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

Drew Adams wrote:

> "The functions" can't be "easier to see" than the single
> function

Many functions that each do little are easier to see than few
functions that each do a lot, because with many functions that
each do little, the function names are often enough to
understand what they do and how they work - and they require
none or very little documentation.

But with few functions that each do a lot, one has to check
the documentation for each function, and the documentation
will be huge, because few functions that each do a lot either
have to have an almost endless list of arguments or rely on an
equally long list of possible keywords to control
their behavior.

For example, (+ ...), (- ...) etc are preferable to
(arithmetic :operation 'addition ...),
(arithmetic :operation 'subtraction ...) etc.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Shrinking the C core

[Yuri Khan]

On Sun, 17 Sept 2023 at 17:46, Emanuel Berg <incal@dataswamp.org> wrote:

> For example, (+ ...), (- ...) etc are preferable to
> (arithmetic :operation 'addition ...),
> (arithmetic :operation 'subtraction ...) etc.

Let’s reframe that in more real-life examples. What is preferable and why:

1. a couple of functions
   a. ‘(my-sort-by SEQ LESSP)’ where LESSP is a function accepting two
elements X and Y and returning ‘t’ when X should be sorted before Y,
and
   b. ‘(my-sort-on SEQ KEY)’ where KEY is a function accepting an
element X and returning a number such that sorting by that number
yields the desired order; or

2. a single function that could be called as ‘(my-sort SEQ :by LESSP)’
or ‘(my-sort SEQ :key KEY)’, with the same semantics as above?

Does your answer change if we want to extend the API to also support
sorting in descending order? If it does, how?

RE: [External] : Re: Shrinking the C core

[Drew Adams]

> Many functions that each do little are easier to see than few
> functions that each do a lot, because with many functions that
> each do little, the function names are often enough to
> understand what they do and how they work - and they require
> none or very little documentation.
> 
> But with few functions that each do a lot, one has to check
> the documentation for each function, and the documentation
> will be huge, because few functions that each do a lot either
> have to have an almost endless list of arguments or rely on an
> equally long list of possible keywords to control
> their behavior.
> 
> For example, (+ ...), (- ...) etc are preferable to
> (arithmetic :operation 'addition ...),
> (arithmetic :operation 'subtraction ...) etc.

You continue to ignore this in your posts:

  The ability to have &optional, &rest, and keyword
  arguments doesn't prevent anyone from _not_ making
  use of any of those and instead defining 8000
  separate functions (to further the exaggeration).

  Do _you_ ever use &optional or &rest when defining
  functions?  If so, why, since you apparently have
  a blanket rule that using multiple separate
  functions is always better?
 
Everything you've said against keyword args (even
just allowing them?) applies equally to &optional
and &rest.  Should they be outlawed or deprecated?

Please answer the question: do you define functions
that use those?  If so, how do you reconcile that
practice with your claim that it's always better to
define separate functions instead?  Why do you use

 (defun foo (arg1 &optional arg2 arg3 arg4)...)

instead of these, since you argue that these must
be better?

 (defun foo1 (arg1) ...)
 (defun foo2 (arg1 arg2) ...)
 (defun foo3 (arg1 arg2 arg3) ...)
 (defun foo4 (arg1 arg2 arg3 arg4) ...)

It's a no-brainer that:

1. Providing the _possibility_ of using &optional,
   &rest - and, yes, keyword args - doesn't _oblige_
   anyone to define functions that use those.

   Such arguments just _allow_ you to define, and
   users to use, a function that takes the place
   of multiple related functions.  Or that serves
   as a helper/workhorse, to _define_ multiple
   related functions.

2. That provides a place and a name for the family
   as a whole, and a place for their _relations_
   to be set forth explicitly in doc.  You get not
   only individual views of particular trees but
   views of tree communities: particular forests.

3. Keyword args let users use fewer actual args
   than when &optional args are used - nils that
   are only positional placeholders disappear.

4. Keyword args make clear what the intention of
   each arg is (it's named!).  Contrast that with
   having to consult the doc each time to figure
   out what each positional arg means.

When calling a function, both (1) the need to stick
in positional-placeholder nils and (2) the need to
identify a keyword arg by its name make function
calls more verbose (an argument you could have made,
but didn't, in favor of not using &optional, &rest,
and keyword args).

It's a tradeoff, for not needing to define and use
more functions.  When defining functions _you_ get
to make that tradeoff decision.  That's the point -
the language doesn't decide for you, by offering
only one possibility.  Lisp says, "You're welcome!"

If every function had no relatives, you might have
an argument.  But if that were the case then no one
would ever define or use &optional or &rest or
keyword args, and those never would have been added
to Lisp in the first place.

(BTW, &rest is essentially just a shortcut for an
explicit list argument.  Some languages make you
pass a vector/sequence/list each time, even when
that's empty: [], "", ().)

Finally, perhaps the most common uses of &optional,
&rest, and keyword args are for defining a family
workhorse function, which is then used to define
other functions with fewer or no such args, which
serve particularly common use cases.

And often the most common use case, even for end
users, is just to call the workhorse function with
no such actual args.  IOW, the "family" function
is often, maybe even typically, defined so that it
can be used as is, with no such args, to provide a
useful default behavior.

Thus it has been, for decades.  And thus it will
continue to be...

RE: [External] : Re: Shrinking the C core

[Drew Adams]

> (format "%d%%" (round (* 100 (/ 466 1637.0)))) ; 28%


OT, but wrt `format':

Recently I've seen some questions on SE.Emacs that
resulted from users trying to use Common Lisp's
`format' in Elisp, that is, trying to use `format'
with DESTINATION first arg and with Common Lisp's
kind of CONTROL-STRING arg.

RE: [External] : Re: Shrinking the C core

[Drew Adams]

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

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

Yuri Khan wrote:

> 1. a couple of functions
>    a. ‘(my-sort-by SEQ LESSP)’ where LESSP is a function accepting two
>        elements X and Y and returning ‘t’ when X should be
>        sorted before Y, and
>    b. ‘(my-sort-on SEQ KEY)’ where KEY is a function accepting an
>        element X and returning a number such that sorting by
>        that number yields the desired order; or
>
> 2. a single function that could be called as ‘(my-sort SEQ
>    :by LESSP)’ or ‘(my-sort SEQ :key KEY)’, with the same
>    semantics as above?
>
> Does your answer change if we want to extend the API to also
> support sorting in descending order? If it does, how?

If there are several tendencies and in particular if those can
be combined one can absolutely use keywords (and extend by
adding more), but then we are at a level of complexity which
would translate to a huge amount of envisioned simple, one or
two argument functions, so instead of doing that, if one were
to stay at the simple function end of the spectrum, one would
use combinations of such simple functions, e.g.
(reverse (sort ... ))

At the opposite end where functions are insanely complex,
keywords are a way to make the interface more clear and
facilitate the submission of arguments from code.

So it is good keywords exist when it is complicated, in
general I prefer it when it is simple but sometimes the
complexity is such it is actually easier to not try to keep it
simple - since that is impossible - but to stay at the complex
side and take it from there.

Optional arguments don't really belong on that simple/complex
scale, rather they should be used when there is an intuitive
default, for example (forward-line &optional N) where
N defaults to 1.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

Drew Adams wrote:

> your claim that it's always better to define separate
> functions instead?

You are claiming that - but I disagree.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

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

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

Drew Adams wrote:

>> (format "%d%%" (round (* 100 (/ 466 1637.0)))) ; 28%
>
> OT, but wrt `format':
>
> Recently I've seen some questions on SE.Emacs that resulted
> from users trying to use Common Lisp's `format' in Elisp,
> that is, trying to use `format' with DESTINATION first arg
> and with Common Lisp's kind of CONTROL-STRING arg.

Maybe we should have a "cl-format" then for the CL format of
`format'?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : Re: Shrinking the C core

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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)

Re: [External] : Re: Shrinking the C core

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > But 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)

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

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

Re: [External] : Re: Shrinking the C core

[Eli Zaretskii]

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

Re: [External] : Re: Shrinking the C core

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

Re: [External] : Re: Shrinking the C core

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

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

Re: [External] : Re: Shrinking the C core

[Eli Zaretskii]

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

Re: [External] : Re: Shrinking the C core

[Eli Zaretskii]

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

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

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

Re: [External] : Re: Shrinking the C core

[Arsen Arsenović]

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

Re: [External] : Re: Shrinking the C core

[Alfred M. Szmidt]

   For instance, I'm not aware of an ``flet'' equivalent in Elisp proper.

There was a flet, but it had different semantics from cl-flet.  And
was thus removed / made obsolete.

Re: [External] : Re: Shrinking the C core

[Emanuel Berg]

Alfred M. Szmidt wrote:

>> For instance, I'm not aware of an ``flet'' equivalent in
>> Elisp proper.
>
> There was a flet, but it had different semantics from
> cl-flet. And was thus removed / made obsolete.

You used to be able to use "labels" for that. But it is now
removed, however there is `cl-labels'.

-- 
underground experts united
https://dataswamp.org/~incal