From: Adam Porter <adam@alphapapa.net>
To: rms@gnu.org
Cc: acm@muc.de, emacs-devel@gnu.org, ulm@gentoo.org
Subject: Re: Why have a #if .... #else .... #endif construct in Emacs Lisp, when we could make the existing code DTRT unchanged?
Date: Tue, 5 Sep 2023 06:06:54 -0500 [thread overview]
Message-ID: <c0200262-dcf5-3656-2a30-2a7052bdb58c@alphapapa.net> (raw)
In-Reply-To: <E1qdJxZ-0005QO-Q2@fencepost.gnu.org>
> > How about making the byte compiler recognize the construct
>
> > (if (< emacs-major-version NUMBER) ...)
>
> > and do this optimization on it?
>
> People seem not to have considered this seriously, but I have not seen
> any serious discussion of a drawback. What flaw or drawback do people
> see in it? It should optimize the existing the existing code with no
> change at all. Isn't that just perfect?
Maybe I'm misunderstanding something, but while that idea does seem
elegant, a potential drawback of that idea would seem to be that
byte-compiled code would need to be recompiled when the user's Emacs
version changed in a relevant way, while checking at runtime would mean
that it would always behave correctly.
It's my impression that most Emacs users don't know about byte-compiling
packages, so when encountering such a problem, most of them wouldn't
know to "M-x package-recompile" to try to solve it. They'd probably end
up posting a message somewhere asking for help, or even making a false
bug report to a package author.
Having said that, am I wrong in thinking that this STATIC-IF suggestion
would suffer from the same problem? Here's the scenario I'm imagining:
1. User is running Emacs vN.
2. User installs package P at vM.
3. Emacs vN+1 is released.
4. Package P is updated to conditionally use features from Emacs vN+1,
and the package is released at vM+1.
5. User installs package P at vM+1 while still using Emacs vN. The
package is byte-compiled for Emacs vN and so compiles out the optional
support for features available on Emacs vN+1.
6. User upgrades Emacs to vN+1 and starts it.
7. User expects package P's support for the new features to be
available, but it's not, and there's no apparent reason why.
8. User files a bug report on package P.
9. Package P's author is confused and asks the user to reinstall the
package.
10. User does so and it works. Everyone shrugs.
11. At some later date, the package author realizes what happened,
perhaps from reading a thread on emacs-devel, and the next time a user
reports the same problem (likely to happen for a year or two, given how
long Emacs versions remain in use), he tells the user to "M-x
package-recompile" it.
Again, maybe I'm missing something obvious, but that scenario seems very
likely to me, so I'm not sure that byte-compiling features conditionally
on the version of Emacs used to compile the file is a great idea.
Runtime checks seem much more robust.
next prev parent reply other threads:[~2023-09-05 11:06 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-28 19:37 Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? Alan Mackenzie
2023-08-28 19:47 ` Ulrich Mueller
2023-08-28 20:06 ` Alan Mackenzie
2023-08-28 21:01 ` Ulrich Mueller
2023-08-28 21:46 ` Alan Mackenzie
2023-08-31 2:07 ` Richard Stallman
2023-08-31 7:50 ` Alan Mackenzie
2023-09-04 1:34 ` Richard Stallman
2023-09-04 10:50 ` Alan Mackenzie
2023-09-04 11:02 ` tomas
2023-09-04 15:19 ` Emanuel Berg
2023-09-04 18:57 ` tomas
2023-09-06 0:58 ` Richard Stallman
2023-09-06 0:58 ` Richard Stallman
2023-09-06 7:28 ` Andreas Schwab
2023-09-06 9:31 ` Alan Mackenzie
2023-09-06 9:56 ` Alan Mackenzie
2023-09-09 0:39 ` Richard Stallman
2023-09-09 10:32 ` Ihor Radchenko
2023-09-10 0:22 ` Richard Stallman
2023-09-10 8:36 ` Ihor Radchenko
2023-09-13 23:53 ` Richard Stallman
2023-09-20 12:59 ` Ihor Radchenko
2023-09-05 0:30 ` Why have a #if .... #else .... #endif construct in Emacs Lisp, when we could make the existing code DTRT unchanged? Richard Stallman
2023-09-05 0:41 ` Emanuel Berg
2023-09-08 17:54 ` Emanuel Berg
2023-09-05 4:37 ` tomas
2023-09-05 5:53 ` Ihor Radchenko
2023-09-05 6:28 ` tomas
2023-09-05 11:06 ` Adam Porter [this message]
2023-09-05 11:26 ` Lynn Winebarger
2023-09-05 14:11 ` Alan Mackenzie
2023-09-08 1:01 ` Richard Stallman
2023-09-08 2:45 ` Po Lu
2023-09-10 0:24 ` Richard Stallman
2023-09-05 8:14 ` Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? Ulrich Mueller
2023-08-28 19:53 ` Emanuel Berg
2023-08-29 9:19 ` Alan Mackenzie
2023-08-29 10:36 ` João Távora
2023-08-29 11:09 ` Ihor Radchenko
2023-08-29 11:20 ` João Távora
2023-08-30 20:48 ` Sean Whitton
2023-08-30 20:59 ` João Távora
2023-09-02 23:12 ` Stefan Monnier via Emacs development discussions.
2023-09-03 0:18 ` Emanuel Berg
2023-09-03 12:27 ` João Távora
2023-08-29 12:54 ` Philip Kaludercic
2023-08-29 13:23 ` Alan Mackenzie
2023-09-02 23:09 ` Stefan Monnier via Emacs development discussions.
2023-08-29 16:28 ` LdBeth
2023-08-29 20:09 ` Stefan Kangas
2023-08-30 10:31 ` Alan Mackenzie
2023-08-30 17:36 ` Stefan Kangas
2023-08-30 18:03 ` Alan Mackenzie
2023-08-30 18:17 ` Stefan Kangas
2023-09-02 15:06 ` Alan Mackenzie
2023-09-02 15:17 ` Eli Zaretskii
2023-09-02 19:43 ` Alan Mackenzie
2023-09-03 4:42 ` Eli Zaretskii
2023-09-03 10:48 ` Alan Mackenzie
2023-09-03 11:02 ` Eli Zaretskii
2023-09-03 13:24 ` Alan Mackenzie
2023-09-02 19:20 ` Philip Kaludercic
2023-09-02 19:37 ` Stefan Kangas
2023-09-02 19:58 ` Alan Mackenzie
2023-09-04 11:12 ` Lynn Winebarger
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=c0200262-dcf5-3656-2a30-2a7052bdb58c@alphapapa.net \
--to=adam@alphapapa.net \
--cc=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=rms@gnu.org \
--cc=ulm@gentoo.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.