[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't t
From: |
Pip Cet |
Subject: |
bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error |
Date: |
Mon, 22 Feb 2021 08:41:03 +0000 |
On Mon, Feb 22, 2021 at 6:20 AM Richard Stallman <rms@gnu.org> wrote:
> I think I agree that funcalling `or' should give an error.
This applies to all macros. I chose #'or as an example because it is
often used as though it were a function, so people might be confused
into trying it (as I have, I must confess).
(funcall #'setq x 3)
also "works", and it's clear in that case that it should not.
I think the right way to fix this is not to macroexpand (funcall #'f)
in eval-expression, but to leave it to the byte compiler to do so; the
byte compiler often assumes that function bindings don't change, so it
would not be a new problem for it to also assume that if #'or is a
macro at compile time, it will be a macro at runtime, so it can avoid
simplifying calls to well-known macros, at least.