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

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

[Pip Cet]

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

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

[Lars Ingebrigtsen]

Pip Cet <pipcet@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

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

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[Philipp Stephani]

Am Fr., 19. Feb. 2021 um 15:03 Uhr schrieb Andreas Schwab
<schwab@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?

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

[Pip Cet]

On Fri, Feb 19, 2021 at 4:46 PM Philipp Stephani <p.stephani2@gmail.com> wrote:
> Am Fr., 19. Feb. 2021 um 15:03 Uhr schrieb Andreas Schwab
> <schwab@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 #').

bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error

[Drew Adams]

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

bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error

[Richard Stallman]

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

bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error

[Andreas Schwab]

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@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error

[Pip Cet]

On Mon, Feb 22, 2021 at 8:25 AM Andreas Schwab <schwab@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.

bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error

[Pip Cet]

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.

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

[Lars Ingebrigtsen]

Pip Cet <pipcet@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