[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why shouldn't we have a #if .... #else .... #endif construct in Emac
From: |
Alan Mackenzie |
Subject: |
Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? |
Date: |
Wed, 30 Aug 2023 18:03:08 +0000 |
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).
Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, LdBeth, 2023/08/29