From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: stefankangas@gmail.com, emacs-devel@gnu.org, mattiase@acm.org
Subject: Re: Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp?
Date: Sun, 3 Sep 2023 10:48:50 +0000 [thread overview]
Message-ID: <ZPRkkvISQjP4yBmb@ACM> (raw)
In-Reply-To: <83r0nf98be.fsf@gnu.org>
Hello, Eli.
On Sun, Sep 03, 2023 at 07:42:13 +0300, Eli Zaretskii wrote:
> > Date: Sat, 2 Sep 2023 19:43:29 +0000
> > Cc: stefankangas@gmail.com, emacs-devel@gnu.org, mattiase@acm.org
> > From: Alan Mackenzie <acm@muc.de>
> > > > ++++
> > > > +** 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.
> What is "interpreted compilation" in Emacs? I'm aware of only two
> compilers in Emacs: the byte compiler and the native compiler. So
> when you talk about "the compiler" above, what does that allude to?
I mean the defmacro and defun macros, particularly when invoked by C-M-x,
etc. Do we have a generic term for these, regardless of whether they are
called interpretatively or in the context of byte/native compilation?
> > 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?
> I don't think I understand the issue: it was discussed in private
> email , and you didn't tell enough for me to understand and form an
> opinion. What do you mean by "condition-case which copes with an
> ancient eval from before lexical binding"?
Sorry. The idea is that package maintainers can copy the source of
static-if directly into their packages so as to be able to use it in
older Emacsen.
In the code for static-if, there's a call to eval with two
arguments, CONDITION and lexical-binding. In (very) old versions of
Emacs, eval would only accept one argument, the form. So in such an old
Emacs, static-if will throw a wrong-number-of-args (or void-variable)
error.
I have proposed catching this error with a condition-case and in the
handler, calling eval again with just one argument.
The other party in the email has opined that static-if should not contain
this condition-case mechanism, and anybody writing for such an old Emacs
should make their own adjustments.
Perhaps it's too small a point to be worth bothering about, but I thought
I'd ask your view anyway.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2023-09-03 10:48 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-28 19:37 Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? Alan Mackenzie
2023-08-28 19:47 ` Ulrich Mueller
2023-08-28 20:06 ` Alan Mackenzie
2023-08-28 21:01 ` Ulrich Mueller
2023-08-28 21:46 ` Alan Mackenzie
2023-08-31 2:07 ` Richard Stallman
2023-08-31 7:50 ` Alan Mackenzie
2023-09-04 1:34 ` Richard Stallman
2023-09-04 10:50 ` Alan Mackenzie
2023-09-04 11:02 ` tomas
2023-09-04 15:19 ` Emanuel Berg
2023-09-04 18:57 ` tomas
2023-09-06 0:58 ` Richard Stallman
2023-09-06 0:58 ` Richard Stallman
2023-09-06 7:28 ` Andreas Schwab
2023-09-06 9:31 ` Alan Mackenzie
2023-09-06 9:56 ` Alan Mackenzie
2023-09-09 0:39 ` Richard Stallman
2023-09-09 10:32 ` Ihor Radchenko
2023-09-10 0:22 ` Richard Stallman
2023-09-10 8:36 ` Ihor Radchenko
2023-09-13 23:53 ` Richard Stallman
2023-09-20 12:59 ` Ihor Radchenko
2023-09-05 0:30 ` Why have a #if .... #else .... #endif construct in Emacs Lisp, when we could make the existing code DTRT unchanged? Richard Stallman
2023-09-05 0:41 ` Emanuel Berg
2023-09-08 17:54 ` Emanuel Berg
2023-09-05 4:37 ` tomas
2023-09-05 5:53 ` Ihor Radchenko
2023-09-05 6:28 ` tomas
2023-09-05 11:06 ` Adam Porter
2023-09-05 11:26 ` Lynn Winebarger
2023-09-05 14:11 ` Alan Mackenzie
2023-09-08 1:01 ` Richard Stallman
2023-09-08 2:45 ` Po Lu
2023-09-10 0:24 ` Richard Stallman
2023-09-05 8:14 ` Why shouldn't we have a #if .... #else .... #endif construct in Emacs Lisp? Ulrich Mueller
2023-08-28 19:53 ` Emanuel Berg
2023-08-29 9:19 ` Alan Mackenzie
2023-08-29 10:36 ` João Távora
2023-08-29 11:09 ` Ihor Radchenko
2023-08-29 11:20 ` João Távora
2023-08-30 20:48 ` Sean Whitton
2023-08-30 20:59 ` João Távora
2023-09-02 23:12 ` Stefan Monnier via Emacs development discussions.
2023-09-03 0:18 ` Emanuel Berg
2023-09-03 12:27 ` João Távora
2023-08-29 12:54 ` Philip Kaludercic
2023-08-29 13:23 ` Alan Mackenzie
2023-09-02 23:09 ` Stefan Monnier via Emacs development discussions.
2023-08-29 16:28 ` LdBeth
2023-08-29 20:09 ` Stefan Kangas
2023-08-30 10:31 ` Alan Mackenzie
2023-08-30 17:36 ` Stefan Kangas
2023-08-30 18:03 ` Alan Mackenzie
2023-08-30 18:17 ` Stefan Kangas
2023-09-02 15:06 ` Alan Mackenzie
2023-09-02 15:17 ` Eli Zaretskii
2023-09-02 19:43 ` Alan Mackenzie
2023-09-03 4:42 ` Eli Zaretskii
2023-09-03 10:48 ` Alan Mackenzie [this message]
2023-09-03 11:02 ` Eli Zaretskii
2023-09-03 13:24 ` Alan Mackenzie
2023-09-02 19:20 ` Philip Kaludercic
2023-09-02 19:37 ` Stefan Kangas
2023-09-02 19:58 ` Alan Mackenzie
2023-09-04 11:12 ` Lynn Winebarger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZPRkkvISQjP4yBmb@ACM \
--to=acm@muc.de \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=mattiase@acm.org \
--cc=stefankangas@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.