Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?

[Alan Mackenzie <acm@muc.de>]

Hello, Richard.

On Sun, Sep 03, 2023 at 21:34:08 -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. ]]]

>   > >   > >       (defadvice .....))

>   > >   > However, when evaluating the containing defun/defmacro rather than byte
>   > >   > compiling it, the irritating warning message will appear with the e-w-c
>   > >   > strategem, but not with hash-if.  ;-)

>   > > How about making the byte compiler recognize the construct
 
>   > >  (if (< emacs-major-version NUMBER) ...)

>   > > and do this optimization on it?

>   > > I think that will DTRT when compiled and when interpreted,
>   > > and it won't require changes in the code of the programs that use it.

> People propose to handle conditions about Emacs version numbers in
> a more optimized way.  I proposed a simple syntax for that.
> Isn't it better?

I don't think it is.

>   > The conditions we want to test are sometimes/frequently expressed in
>   > terms of the (non-)existence of variables, etc.  It would be
>   > inconvenient for package maintainers to have to determine "critical"
>   > Emacs version numbers to use.

> I don't follow you, Haven't we been talking about conditions on Emacs
> versions all along in this discussion?  I did not propose that as a
> change, I carried it along.

For example, in CC Mode there is a chunk of code looking like ....

  (when (fboundp 'electric-indent-local-mode) ; Emacs 24.4 or later.
    (electric-indent-local-mode (if c-electric-flag 1 0)))

, and there are quite a few instances like it.  Here, there is a comment
about which versions are relevant, but that is somewhat unusual.  Note
here that we would have to test both the major and minor version numbers
to do this correctly.

I intend to replace that code with

  (static-if (fboundp 'electric-indent-local-mode) ; Emacs 24.4 or later.
    (electric-indent-local-mode (if c-electric-flag 1 0)))

..  (hash-if has been renamed static-if.)  It would be more work to
replace it with

  (when (or (> emacs-major-version 24)
            (and (= emacs-major-version 24)
	         (>= emacs-minor-version 4)))
    (electric-indent-local-mode (if c-electric-flag 1 0)))

, and that's not even taking into account the one-time effort to put
special handling into >, >=, <, <=, =, /= (?etc.) for
emacs-m\(aj\|in\)or-version.  I haven't looked into this in any detail,
but it might be quite a lot of work.

>   > Why do you think a more restricted test of the version number would be
>   > better than a more general test?

> If people would like other tests too, I have nothing against them.
> The issue is how to implement whatever tests we support.  If they can
> be done at compiler time, isn't this the better implementation?

static-if is a completely ordinary macro which is 10 lines long
(including doc string), and there's a new section in the elisp manual for
it.  Amending the evaluator and byte compiler for special handling for
emacs-m..or-version would be more than 10 lines.

There are currently just 45 occurrences of emacs-major-mode in our Lisp
sources, and most of these are comparisons with a decimal number.
Editing each occurrence by hand to use static-if would still be less work
than amending the evaluator and byte compiler for special handling.

We have just over 2000 occurrences of boundp and fboundp, some of which
will be used to isolate code to be evaluated only when the
variable/function is bound or not bound, as in the above CC Mode snippet.

> I guess I don't follow.  Why do you prefer `hash-if' rather
> than this simple compile-time syntax?  Why change the syntax rather
> than using the syntax we use now?

Because of the complexity of adding suitable special handling for
emacs-m..nor mode to the evaluator and byte compiler compared with the
simplicity of the new macro, and the relative ease of adapting existing
code.

> -- 
> 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).