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

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

[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

[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

[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

[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

[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

[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