[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why have a #if .... #else .... #endif construct in Emacs Lisp, when
From: |
Alan Mackenzie |
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 14:11:06 +0000 |
Hello, Richard.
On Mon, Sep 04, 2023 at 20:30:25 -0400, Richard Stallman wrote:
> [[[ 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. ]]]
> > 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, ....
It was actually the first thing I considered when the original problem
occurred to me. We have a similar optimisation in place for (featurep
xemacs). But then, the number of ways emacs-major-version (to say
nothing of emacs-minor-version) can be used is large (starting with <,
<=, >, >=, =, /=, eq, eql, equal, and extending to predicates involving
e-minor-v), that it would be at least somewhat difficult to apply in
practice.
> .... but I have not seen any serious discussion of a drawback.
I outlined some drawbacks in my post of yesterday evening (Monday
2022-09-04), European time.
> What flaw or drawback do people see in it?
The above. Plus, some (possibly most) of the predicates we want to
optimise out are expressed in terms of present/absent features rather
than numeric version numbers. There are just 45 occurrences of
emacs-major-version in the Lisp sources, over 2000 occurrences of boundp
and fboundp. We could convert (some of) those 45 to use static-if in
less time than it would take to amend the interpreter and byte-compiler
to handler emacs-major-version specially.
> It should optimize the existing the existing code with no change at
> all. Isn't that just perfect?
Sadly, no it's not. It would only do part of the job which is to be
done. It would make some parts of Emacs more complicated.
> --
> 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)
--
Alan Mackenzie (Nuremberg, Germany).
- Re: Why have a #if .... #else .... #endif construct in Emacs Lisp, when we could make the existing code DTRT unchanged?, Richard Stallman, 2023/09/04
- Re: Why have a #if .... #else .... #endif construct in Emacs Lisp, when we could make the existing code DTRT unchanged?, Emanuel Berg, 2023/09/04
- Re: Why have a #if .... #else .... #endif construct in Emacs Lisp, when we could make the existing code DTRT unchanged?, tomas, 2023/09/05
- Re: Why have a #if .... #else .... #endif construct in Emacs Lisp, when we could make the existing code DTRT unchanged?, Adam Porter, 2023/09/05
- Re: Why have a #if .... #else .... #endif construct in Emacs Lisp, when we could make the existing code DTRT unchanged?, Lynn Winebarger, 2023/09/05
- Re: Why have a #if .... #else .... #endif construct in Emacs Lisp, when we could make the existing code DTRT unchanged?,
Alan Mackenzie <=