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

[Alan Mackenzie]

Hello, Stefan.

On Wed, Aug 30, 2023 at 19:36:20 +0200, Stefan Kangas wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > > 1. Would it be hard to make the byte-compiler not warn in the
> > > situation you describe?
> >
> > (That situation being where an obsolete function/variable is tested for,
> > and is used or not used according to the result of the test.)  It would
> > not be too hard, and the scheme I'm proposing (with help from Philip K.)
> > is one way of doing this.

> I'm asking because we already have special casing in place for
> (featurep 'xemacs) -- we just constant fold it -- so I'm wondering if
> it would make sense to do the same here.  See bytecomp.el:5671.

I looked at that, and came to the conclusion it doesn't make sense.  The
mechanics there would be to evaluate (if some-condition FOO BAR) at
compilation time and replace it with either FOO or BAR.  The problem is
some-condition can vary at run time, for example by setting an option,
so it would be more trouble than it's worth.

> It's not the same situation exactly though, as we will often be able
> to run bytecode from Emacs N+1 on Emacs N, whereas XEmacs/Emacs
> byte-code compatibility is both long gone and in all likelihood not
> coming back.

Indeed, not.

> > It may be, but it's clumsy.  We would need such an alias for _each_
> > function/variable which has been declared obsolete.  In my proposed
> > mechanism, by contrast, one would just need to replace an `if' form by a
> > `hash-if'.

> Right.  I guess this has been the state of the art in Emacs Lisp so
> far, though.  And then `hash-if' itself won't exist in Emacs 24
> either, of course, so depending on how ambitious people are with
> backwards-compatibility they'll have to lug around compatibility
> boiler-plate for that too.

The current size of hash-if, including doc-string, is 10 lines.  Add in
an extra line for (if (not fboundp 'hash-if) ....), and we come to 11
lines.  I think, given the heartaches and headaches suffered by package
maintainers when variables/functions become obsolete or vanish, this
would not be much of a hardship.

> If we do go with a new macro, I'd propose naming it `static-if' (as in
> APEL) instead of `hash-if', because the latter name seems to wrongly
> suggest that it has to do with hashing.

I looked at APEL, and its code was near identical to what I (with help
from PK) wrote.  I'd have nothing against the name static-if instead.
As long as this doesn't raise copyright assignment problems, assuming
the authors of APEL haven't assigned copyright to the FSF.

> Our legacy is also older than even the C preprocessor.

:-)

-- 
Alan Mackenzie (Nuremberg, Germany).