GNU bug report logs - #46636
28.0.50; M-: (funcall #'or) doesn't throw an error

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46636 in the body.
You can then email your comments to 46636 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; M-: (funcall #'or) doesn't throw an error
Date: Fri, 19 Feb 2021 13:26:25 +0000

Recipe starting from emacs -Q:

M-: (funcall #'or) RET

Expected result:

An error, as `or' is not a function.

Actual result:

nil
------
Effectively, this makes `funcall' behave as though it were a macro,
even though it is a function.

Probably not a serious issue, but it can confuse people into thinking
that "funcall" accepts macros in general, which it doesn't do. It
certainly confused me (the byte compiler also mis-compiles (apply #'or
nil), which did not help).

Message #8 received at 46636 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 46636 <at> debbugs.gnu.org
Subject: Re: bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
Date: Fri, 19 Feb 2021 14:35:42 +0100

Pip Cet <pipcet <at> gmail.com> writes:

> Recipe starting from emacs -Q:
>
> M-: (funcall #'or) RET
>
> Expected result:
>
> An error, as `or' is not a function.

M-: (funcall 'or)
-> funcall: Invalid function: #<subr or>

So, indeed, that does seem rather inconsistent.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 46636 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 46636 <at> debbugs.gnu.org
Subject: Re: bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
Date: Fri, 19 Feb 2021 15:01:56 +0100

On Feb 19 2021, Pip Cet wrote:

> Recipe starting from emacs -Q:
>
> M-: (funcall #'or) RET

If you want authentic results, use ielm, not eval-expression.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #14 received at 46636 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 46636 <at> debbugs.gnu.org, Pip Cet <pipcet <at> gmail.com>
Subject: Re: bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
Date: Fri, 19 Feb 2021 17:46:16 +0100

Am Fr., 19. Feb. 2021 um 15:03 Uhr schrieb Andreas Schwab
<schwab <at> linux-m68k.org>:
>
> On Feb 19 2021, Pip Cet wrote:
>
> > Recipe starting from emacs -Q:
> >
> > M-: (funcall #'or) RET
>
> If you want authentic results, use ielm, not eval-expression.
>


Ah, so the rewrite that macroexpand-all (in macroexp--expand-all)
performs is the culprit here. Maybe it should only rewrite if the
first argument is indeed a function, or an autoload of a function?

Message #17 received at 46636 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 46636 <at> debbugs.gnu.org, Andreas Schwab <schwab <at> linux-m68k.org>
Subject: Re: bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
Date: Fri, 19 Feb 2021 18:10:26 +0000

On Fri, Feb 19, 2021 at 4:46 PM Philipp Stephani <p.stephani2 <at> gmail.com> wrote:
> Am Fr., 19. Feb. 2021 um 15:03 Uhr schrieb Andreas Schwab
> <schwab <at> linux-m68k.org>:
> >
> > On Feb 19 2021, Pip Cet wrote:
> >
> > > Recipe starting from emacs -Q:
> > >
> > > M-: (funcall #'or) RET
> >
> > If you want authentic results, use ielm, not eval-expression.
>
> Ah, so the rewrite that macroexpand-all (in macroexp--expand-all)
> performs is the culprit here.

Yes, I think so.

> Maybe it should only rewrite if the
> first argument is indeed a function, or an autoload of a function?

I'm unconvinced it's worth it at all to rewrite funcalls or applys,
either in macroexp or in the byte compiler.

But if we have to, we have to make sure (apply #'or nil) and (funcall
#'or) are rejected somewhere (maybe as early as the #').

Message #20 received at 46636 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Pip Cet <pipcet <at> gmail.com>, "46636 <at> debbugs.gnu.org" <46636 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw
 an error
Date: Fri, 19 Feb 2021 18:28:29 +0000

> M-: (funcall #'or) RET
> Expected result:
> An error, as `or' is not a function.
> Actual result:
> nil
> ------
> Effectively, this makes `funcall' behave as though it were a macro,
> even though it is a function.
> 
> Probably not a serious issue, but it can confuse people into thinking
> that "funcall" accepts macros in general, which it doesn't do. It
> certainly confused me (the byte compiler also mis-compiles (apply #'or
> nil), which did not help).

Yeah, this is bad, IMO.  Confuses users and leads
them down the garden path.  Common Lisp and other
Lisps haven't done this, AFAIK.

Message #23 received at 46636 <at> debbugs.gnu.org (full text, mbox):

From: Richard Stallman <rms <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 46636 <at> debbugs.gnu.org, pipcet <at> gmail.com
Subject: Re: bug#46636: [External] : bug#46636: 28.0.50;
 M-: (funcall #'or) doesn't throw an error
Date: Mon, 22 Feb 2021 01:20:03 -0500

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I think I agree that funcalling `or' should give an error.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Message #26 received at 46636 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Richard Stallman <rms <at> gnu.org>
Cc: 46636 <at> debbugs.gnu.org, pipcet <at> gmail.com, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or)
 doesn't throw an error
Date: Mon, 22 Feb 2021 09:25:30 +0100

On Feb 22 2021, Richard Stallman wrote:

> I think I agree that funcalling `or' should give an error.

It does.  The problem is in macroexp--expand-all, called by
eval-expression, which transforms this into a no-op.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Message #29 received at 46636 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: rms <at> gnu.org
Cc: 46636 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: 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 <at> 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.

Message #32 received at 46636 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> gmail.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 46636 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>,
 Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or)
 doesn't throw an error
Date: Mon, 22 Feb 2021 09:16:15 +0000

On Mon, Feb 22, 2021 at 8:25 AM Andreas Schwab <schwab <at> linux-m68k.org> wrote:
> > I think I agree that funcalling `or' should give an error.
> It does.

Just to clarify: your point is that there are non-standard ways of
executing Emacs Lisp which do not suffer from this bug, right? Or is
it that the bug isn't in Ffuncall (it isn't)?

> The problem is in macroexp--expand-all, called by
> eval-expression, which transforms this into a no-op.

There and in the byte compiler, which does the same thing to (apply
...) forms, too.

Message #35 received at 46636 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 46636 <at> debbugs.gnu.org
Subject: Re: bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
Date: Fri, 17 Jun 2022 19:39:23 +0200

Pip Cet <pipcet <at> gmail.com> writes:

> Recipe starting from emacs -Q:
>
> M-: (funcall #'or) RET
>
> Expected result:
>
> An error, as `or' is not a function.
>
> Actual result:
>
> nil

I can reproduce this in Emacs 28, but in Emacs 29 we now get:

Debugger entered--Lisp error: (invalid-function #<subr or>)
  or()
  funcall(or)
  eval((funcall #'or) t)
  eval-expression((funcall #'or) nil nil 127)
  funcall-interactively(eval-expression (funcall #'or) nil nil 127)

So it seems like this has been fixed now, and I'm therefore closing this
bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.