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

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 46834 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: bug#46834: 28.0.50; byte-compiling the standard counter closure fails
Date: Mon, 1 Mar 2021 16:41:58 +0000

On Mon, Mar 1, 2021 at 4:15 PM Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
> > That said, the comment in byte-compile--reify-function is incorrect:
>
> [ I don't see which comment you're referring to.  ]

The docstring, sorry. It says the return value evaluates to FUN, which
is incorrect (but, IMHO at least, this behavior is desirable and
consistent, at least, with the way byte-compile changes string
identities).

> > 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 agree, it is repulsive. I wasn't going to mention it for that reason
:-) (Also for the reason that I wasn't sure whether anything would
break out of the cl-symbol-macrolet jail (no luck so far...))

Pip

Previous Next

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