all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.



  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.