From: Adam Porter <adam@alphapapa.net>
To: rms@gnu.org
Cc: acm@muc.de, acorallo@gnu.org, emacs-devel@gnu.org
Subject: Re: Declaring Lisp function types
Date: Thu, 29 Feb 2024 00:10:15 -0600 [thread overview]
Message-ID: <d217250c-90a7-47e2-b97b-9d64068bd733@alphapapa.net> (raw)
In-Reply-To: <E1rfXRJ-0002mJ-3C@fencepost.gnu.org>
> > I worry that these declarations will become frequent, even pervasive,
> > and then effectively compulsory. Then we won't have Lisp any more,
> > we'll have something more like C.
>
> > I think somebody said somewhere that the declarations will be
> > "voluntary", but things that start off voluntary have a nasty habit of
> > first becoming pervasive, then all but universal, and then compulsory.
I don't think these are fair arguments. They're beyond speculative.
We're here because we want to write this kind of software in Emacs Lisp,
not in C. No one wants mandatory type declarations. And the Common
Lisp model, which Andrea seems to be inspired by and generally
following, does not make such declarations mandatory either.
The same kind of argument could be made about, e.g. Edebug
instrumentation declarations: "If we allow macros to have these, they
could start off voluntary, but then become pervasive, then compulsory.
So we'd better not have them at all, then." Obviously, they have not
turned out that way; they are added where they are useful and needed,
and they are of great benefit. No one has any intention of making them
mandatory; if they are not provided, then the macro is simply not
instrumented as usefully. There is no slippery slope here.
In the same way, if a function has type declarations, and--someday--the
compiler could use them to produce more efficient code, that would be
great. Otherwise, the function will be compiled as it is now.
This is, as far as I can tell, what Andrea has always intended to do,
time permitting, and he has made this clear from all of his writing on
the topic for the past few years. To suggest that he intends otherwise
would seem quite unfair to him.
> That is my concern as well. If we let native compilation
> lure us down the path of changing the Emacs Lisp language
> so as to make native-compiled code faster, there is almost
> no limit to how much time we could put into it. There are
> always things we could do to keep optimizing some cases.
>
> This will tend to draw effort away from other sorts of improements in
> GNU Emacs. We should decline to go down that path.
I don't think that's a reasonable way to view this matter. Emacs is
developed voluntarily. It's a rare occasion that someone comes along
who has the expertise, interest, and time to contribute something as
challenging as compiler optimizations, such as Andrea has graciously
given to us (really, a whole new compiler implementation). When it
happens, who are we to say that they should apply their effort
elsewhere. We should gratefully accept their contributions and
encourage more of them as they are able to provide.
Emacs needs these kinds of significant developments--ones which happen
rarely but provide benefits for many years--to sustain it in the face of
competition that's developed by teams of full-time engineers working at
large companies. Woe unto us if we turn them away by asking them to
volunteer their time on something not according to their interest.
next prev parent reply other threads:[~2024-02-29 6:10 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 16:02 Declaring Lisp function types Andrea Corallo
2024-02-23 23:35 ` Adam Porter
2024-02-24 7:10 ` Eli Zaretskii
2024-02-24 8:53 ` Tomas Hlavaty
2024-02-24 9:08 ` Adam Porter
2024-02-24 9:24 ` Andrea Corallo
2024-02-24 15:13 ` Tomas Hlavaty
2024-02-24 15:21 ` Tomas Hlavaty
2024-02-24 15:24 ` Tomas Hlavaty
2024-02-24 8:56 ` Adam Porter
2024-02-24 10:03 ` Eli Zaretskii
2024-02-25 7:35 ` Adam Porter
2024-02-24 9:21 ` Andrea Corallo
2024-02-25 17:04 ` Alan Mackenzie
2024-02-25 17:15 ` Eli Zaretskii
2024-02-25 17:16 ` [External] : " Drew Adams
2024-02-26 16:25 ` Andrea Corallo
2024-02-29 3:50 ` Richard Stallman
2024-02-29 6:10 ` Adam Porter [this message]
2024-02-29 9:02 ` Andrea Corallo
2024-02-26 3:38 ` Richard Stallman
2024-02-26 16:38 ` [External] : " Drew Adams
2024-02-26 16:54 ` Eli Zaretskii
2024-02-26 17:44 ` Andrea Corallo
2024-02-26 16:52 ` Andrea Corallo
2024-02-26 18:10 ` Tomas Hlavaty
2024-03-02 21:19 ` Stefan Monnier via Emacs development discussions.
2024-03-03 9:52 ` Andrea Corallo
2024-03-03 14:52 ` Stefan Monnier
2024-03-03 17:31 ` Andrea Corallo
2024-03-03 18:13 ` Stefan Monnier
2024-03-15 16:49 ` Andrea Corallo
2024-03-15 18:19 ` Tomas Hlavaty
2024-03-15 18:38 ` Eli Zaretskii
2024-03-16 13:39 ` Tomas Hlavaty
2024-03-16 14:06 ` Eli Zaretskii
2024-03-16 14:56 ` Tomas Hlavaty
2024-03-16 15:43 ` Emanuel Berg
2024-03-16 15:44 ` Eli Zaretskii
2024-03-16 15:54 ` Emanuel Berg
2024-03-18 8:55 ` Lele Gaifax
2024-03-16 0:01 ` Adam Porter
2024-03-18 9:25 ` Andrea Corallo
2024-03-26 10:13 ` Andrea Corallo
2024-03-26 10:28 ` Christopher Dimech
2024-03-26 12:55 ` Eli Zaretskii
2024-03-26 16:46 ` Andrea Corallo
2024-04-29 17:48 ` Andrea Corallo
2024-04-29 17:55 ` Stefan Monnier
2024-04-29 18:42 ` Andrea Corallo
2024-04-30 14:55 ` Eli Zaretskii
2024-04-30 18:29 ` Stefan Monnier
2024-05-01 20:57 ` Andrea Corallo
2024-05-01 21:06 ` Stefan Monnier
2024-05-02 6:16 ` Eli Zaretskii
2024-05-02 10:16 ` Andrea Corallo
2024-05-02 6:15 ` Eli Zaretskii
2024-05-02 10:12 ` Andrea Corallo
2024-05-02 11:15 ` Eli Zaretskii
2024-05-02 13:20 ` Stefan Monnier
2024-05-01 20:54 ` Andrea Corallo
2024-05-02 10:22 ` Eli Zaretskii
2024-05-02 15:18 ` Andrea Corallo
2024-05-02 16:32 ` Eli Zaretskii
2024-03-26 13:05 ` Mattias Engdegård
2024-03-26 13:44 ` Stefan Monnier
2024-03-26 14:28 ` Joost Kremers
2024-03-26 14:37 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2024-03-16 7:46 Arthur Miller
2024-03-16 15:46 ` Emanuel Berg
2024-03-18 9:02 ` Andrea Corallo
2024-03-18 9:58 ` Arthur Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d217250c-90a7-47e2-b97b-9d64068bd733@alphapapa.net \
--to=adam@alphapapa.net \
--cc=acm@muc.de \
--cc=acorallo@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.