unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
@ 2021-02-19 13:26 Pip Cet
  2021-02-19 13:35 ` Lars Ingebrigtsen
                   ` (3 more replies)
  0 siblings, 4 replies; 11+ messages in thread
From: Pip Cet @ 2021-02-19 13:26 UTC (permalink / raw)
  To: 46636

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
  2021-02-19 13:26 bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error Pip Cet
@ 2021-02-19 13:35 ` Lars Ingebrigtsen
  2021-02-19 14:01 ` Andreas Schwab
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 11+ messages in thread
From: Lars Ingebrigtsen @ 2021-02-19 13:35 UTC (permalink / raw)
  To: Pip Cet; +Cc: 46636

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
  2021-02-19 13:26 bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error Pip Cet
  2021-02-19 13:35 ` Lars Ingebrigtsen
@ 2021-02-19 14:01 ` Andreas Schwab
  2021-02-19 16:46   ` Philipp Stephani
  2021-02-19 18:28 ` bug#46636: [External] : " Drew Adams
  2022-06-17 17:39 ` Lars Ingebrigtsen
  3 siblings, 1 reply; 11+ messages in thread
From: Andreas Schwab @ 2021-02-19 14:01 UTC (permalink / raw)
  To: Pip Cet; +Cc: 46636

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
  2021-02-19 14:01 ` Andreas Schwab
@ 2021-02-19 16:46   ` Philipp Stephani
  2021-02-19 18:10     ` Pip Cet
  0 siblings, 1 reply; 11+ messages in thread
From: Philipp Stephani @ 2021-02-19 16:46 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: 46636, Pip Cet

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?





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
  2021-02-19 16:46   ` Philipp Stephani
@ 2021-02-19 18:10     ` Pip Cet
  0 siblings, 0 replies; 11+ messages in thread
From: Pip Cet @ 2021-02-19 18:10 UTC (permalink / raw)
  To: Philipp Stephani; +Cc: 46636, Andreas Schwab

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
  2021-02-19 13:26 bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error Pip Cet
  2021-02-19 13:35 ` Lars Ingebrigtsen
  2021-02-19 14:01 ` Andreas Schwab
@ 2021-02-19 18:28 ` Drew Adams
  2021-02-22  6:20   ` Richard Stallman
  2022-06-17 17:39 ` Lars Ingebrigtsen
  3 siblings, 1 reply; 11+ messages in thread
From: Drew Adams @ 2021-02-19 18:28 UTC (permalink / raw)
  To: Pip Cet, 46636@debbugs.gnu.org

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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
  2021-02-19 18:28 ` bug#46636: [External] : " Drew Adams
@ 2021-02-22  6:20   ` Richard Stallman
  2021-02-22  8:25     ` Andreas Schwab
  2021-02-22  8:41     ` Pip Cet
  0 siblings, 2 replies; 11+ messages in thread
From: Richard Stallman @ 2021-02-22  6:20 UTC (permalink / raw)
  To: Drew Adams; +Cc: 46636, pipcet

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







^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
  2021-02-22  6:20   ` Richard Stallman
@ 2021-02-22  8:25     ` Andreas Schwab
  2021-02-22  9:16       ` Pip Cet
  2021-02-22  8:41     ` Pip Cet
  1 sibling, 1 reply; 11+ messages in thread
From: Andreas Schwab @ 2021-02-22  8:25 UTC (permalink / raw)
  To: Richard Stallman; +Cc: 46636, pipcet

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
  2021-02-22  6:20   ` Richard Stallman
  2021-02-22  8:25     ` Andreas Schwab
@ 2021-02-22  8:41     ` Pip Cet
  1 sibling, 0 replies; 11+ messages in thread
From: Pip Cet @ 2021-02-22  8:41 UTC (permalink / raw)
  To: rms; +Cc: 46636

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.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#46636: [External] : bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
  2021-02-22  8:25     ` Andreas Schwab
@ 2021-02-22  9:16       ` Pip Cet
  0 siblings, 0 replies; 11+ messages in thread
From: Pip Cet @ 2021-02-22  9:16 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: 46636, Richard Stallman

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.





^ permalink raw reply	[flat|nested] 11+ messages in thread

* bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error
  2021-02-19 13:26 bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error Pip Cet
                   ` (2 preceding siblings ...)
  2021-02-19 18:28 ` bug#46636: [External] : " Drew Adams
@ 2022-06-17 17:39 ` Lars Ingebrigtsen
  3 siblings, 0 replies; 11+ messages in thread
From: Lars Ingebrigtsen @ 2022-06-17 17:39 UTC (permalink / raw)
  To: Pip Cet; +Cc: 46636

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





^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2022-06-17 17:39 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-19 13:26 bug#46636: 28.0.50; M-: (funcall #'or) doesn't throw an error Pip Cet
2021-02-19 13:35 ` Lars Ingebrigtsen
2021-02-19 14:01 ` Andreas Schwab
2021-02-19 16:46   ` Philipp Stephani
2021-02-19 18:10     ` Pip Cet
2021-02-19 18:28 ` bug#46636: [External] : " Drew Adams
2021-02-22  6:20   ` Richard Stallman
2021-02-22  8:25     ` Andreas Schwab
2021-02-22  9:16       ` Pip Cet
2021-02-22  8:41     ` Pip Cet
2022-06-17 17:39 ` Lars Ingebrigtsen

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).