emacs-devel
[Top][All Lists]
Advanced

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]