GNU bug report logs - #59576
29.0.50; named-let doesn't support dynamic binding

Previous Next

Full log

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

From: Tom Levy <tomlevy93 <at> gmail.com>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 59576 <at> debbugs.gnu.org
Subject: Re: bug#59576: 29.0.50; named-let doesn't support dynamic binding
Date: Sat, 26 Nov 2022 23:36:10 +1300

Personally I'm fine with `named-let' signalling an error in dynamic
binding mode.

(Regarding worse code in lexical binding mode: There are workarounds.
An ugly one is to include both versions of `named-let' and switch
between them depending on the binding mode. Another solution is to
teach the byte-compiler to inline funcalls to let-bound lambdas;
that's more elegant and might also benefit other code, but I have no
idea how difficult it would be to implement.)

On Sat, 26 Nov 2022 at 22:49, Mattias Engdegård <mattiase <at> acm.org> wrote:
>
> `named-let` being a looping construct, it makes little sense to use it in dynamic binding where TCO opportunities are severely limited. Ideally we should just signal an error if an attempt to use it in dynbound code is made. Users will thank us for that (at least they should, if they have any sense).
>
> Second-best would be to inhibit all TCO in dynbound code but whom would that really benefit?
>
> (Regarding your proposal, generating worse code in lexbind mode isn't a wonderful outcome.)
>

Previous Next

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