GNU bug report logs - #54802
OClosure: Make `interactive-form` a generic function

Previous Next

Full log

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 54802 <at> debbugs.gnu.org
Subject: Re: bug#54802: OClosure: Make `interactive-form` a generic function
Date: Fri, 15 Apr 2022 09:37:43 +0800

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> Hmm... odd.  I know the problem doesn't show up if you have
> `gnus-score.el` loaded beforehand, but otherwise I wonder how you dodged
> that "bullet" (not that it matters, it's fixed now anyway; just curious).

Probably because every autoload that could cause problems was already
loaded.

> Talking about curious, I wonder what you use that loop for.

It was originally supposed to demonstrate the feasibility of a
"context-sensitive" menu in Emacs, i.e. one that displays commands
pertinent to the region when it is active, etc.

But in the end I made a completing-read wrapper around it, which does
make it easier to find some odd commands I can't remember.

>> OClosures are records, right?  There's no other record type that can be
>> a function with an interactive form, so we could just use `recordp'
>> instead of calling into Lisp for that.
>
> They're somewhat like records but they're not `recordp`, they're `functionp`.

[...]

> Part of the 2x slowdown is due to generic dispatch but part is due to
> the fact the code is in ELisp rather than in C, so even a "perfectly
> fast" generic dispatch wouldn't get us back the factor 2x.
> And speeding up generic dispatch is not super easy.

Hmm, so what about having a special "OClosure" pseudovector type on the
C level which would otherwise behave like byte-code functions, but
behave specially in `interactive-form'?

Thanks.

Previous Next

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