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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

Thanks for the feedback.

On Sat, Sep 02, 2023 at 18:17:51 +0300, Eli Zaretskii wrote:
> > Date: Sat, 2 Sep 2023 15:06:46 +0000
> > Cc: emacs-devel@gnu.org,
> >  Mattias Engdegård <mattiase@acm.org>
> > From: Alan Mackenzie <acm@muc.de>

> > +@node Conditional Compilation
> > +@section Conditional Compilation
> > +
> > +  There will be times when you want certain code to be compiled only
> > +when a certain condition holds.  This is particularly the case when
> > +maintaining Emacs packages; to keep the package compatible with older
> > +versions of Emacs you may need to use a function or variable which has
> > +become obsolete in the current version of Emacs.
> > +
> > +  You could just use a conditional form to select the old or new form
> > +at run time, but this tends to output annoying warning messages about
> > +the obsolete function/variable.  For such situations, the macro
> > +@code{static-if} comes in handy.  It is inspired by the conditional
> > +compilation directives like @code{#if} in C like languages, and is
> > +patterned after the special form @code{if} (@pxref{Conditionals}).
> > +
> > +  To use this facility for an older version of Emacs, copy the source
> > +for @code{static-if} from the Emacs source file @file{lisp/subr.el}
> > +into your package.

> Thanks, but I think the references to #if make the documentation less
> helpful than it could be.  This manual is for Lisp programmers, and
> those are not necessarily familiar with C and its preprocessor
> directives.  So I think it would be better if you removed the
> references to cpp.  If you think removing that would make the
> documentation less self-explanatory, I suggest to add explanations
> that are based on Lisp and on typical situations while writing Lisp
> programs, not on cpp.

OK, I've removed the bit "It is inspired by .... C like languages"
leaving just "It is patterned after the special form @code{if} ..." of
the sentence.

I thought the comparison with C might be helpful for a lot of users, but
I can see how it might be confusing instead.

> > --- a/etc/NEWS
> > +++ b/etc/NEWS
> > @@ -855,6 +855,10 @@ Use 'define-minor-mode' and 'define-globalized-minor-mode' instead.
> >  See the "(elisp) Porting Old Advice" node for help converting them
> >  to use 'advice-add' or 'define-advice' instead.
> >  
> > ++++
> > +** There is now conditional compilation, based on the C language's #if.
> > +To use this, see the new macro 'static-if'.

> Same here.  Here, it is actually worse: "based on C language's #if"
> could be misinterpreted as meaning the implementation is based on #if
> in some way.  I would suggest the following text in NEWS:

>  ** New macro 'static-if' for conditional byte-compilation of code.
>  This macro hides a form from the byte-compiler based on a
>  compile-time condition.  This is handy for avoiding byte-compilation
>  warnings about code that will never actually run under some
>  conditions.

static-if actually works for interpreted compilation as well as byte
compilation, so I've removed two "byte-"s from your text, leaving:

+++
** New macro 'static-if' for conditional compilation of code.
This macro hides a form from the compiler based on a compile-time
condition.  This is handy for avoiding byte-compilation warnings about
code that will never actually run under some conditions.

I think it's now ready to commit, except ....

I've had some private email which suggested that perhaps static-if
should not include the condition-case which copes with an ancient eval
from before lexical binding.  I can see some merit in the argument
(lexical binding happened in 24.1, I think), but on the other hand, that
extreme backwards compatibility doesn't really cost us anything
(static-if is just 13 lines of code).

What do you think?

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).