[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59576: 29.0.50; named-let doesn't support dynamic binding
From: |
Tom Levy |
Subject: |
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@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.)
>