GNU bug report logs - #46834
28.0.50; byte-compiling the standard counter closure fails

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 46834 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#46834: 28.0.50; byte-compiling the standard counter closure
 fails
Date: Mon, 01 Mar 2021 11:15:05 -0500

>> and notice that the counter is not shared between the two functions :-(
> I'd noticed that, but figured Stefan wouldn't accept "partial byte
> compilation" as a reasonable bug scenario :-)

I'd have to ask him, but he'd probably roll his eyes and complain about
this use case yet again.

> That said, the comment in byte-compile--reify-function is incorrect:

[ I don't see which comment you're referring to.  ]

> since closures use alists and "let" uses proper lists, we can't share
> structure between them, so the return value will be equivalent to a
> snapshot of FUN, not "equal" to FUN itself. OTOH, even changing that
> wouldn't help as byte-compiled closures use a third format to store
> the bindings, IIUC.

I think we could make the shared state work if we turned

    (closure ((VAR . VAL) ...) ...)

into something like

    (cl-symbol-macrolet ((VAR (cdr ',CONSCELL)) ...) ...)

I find the idea pretty repulsive, tho.

> I've been meaning to ask, is there anything like an XFAIL test in our
> current framework? This would be an excellent use for one of those.

I don't know what is XFAIL, and I'm not very knowledgeable about our
test infrastructure, so you might want to ask elsewhere.


        Stefan

Previous Next

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