[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: |
Stefan Kangas |
Subject: |
Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? |
Date: |
Wed, 30 Aug 2023 19:36:20 +0200 |
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. 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.
> 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.
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. Our legacy is also older than
even the C preprocessor.
Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?, LdBeth, 2023/08/29