Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

[EricT <tw...@gm...>]

Hi Florent,

Thanks for thinking through the bridge token approach - it's clever!
However, I think you're right that the path forward is TCL_TOKEN_SUB_EXPR
with new compiler code that doesn't assume buffer continuity.

The challenge with bridge tokens is that every piece of code doing pointer
arithmetic would need to be taught to recognize and skip over them - that
could be dozens of places throughout the codebase. The "new token type with
new code" approach is cleaner because the new code paths don't inherit the
old assumptions.

I look forward to seeing what you discover as you explore the
TCL_TOKEN_SUB_EXPR approach. Understanding the compiler deeply will be
valuable for getting this right.

Regarding the lseq naked expression issue - I was involved in the TIP
process that led to lseq, though Brian Griffin did the implementation. The
naked expression feature allows things like lseq 1 to $x*2-1 (note: still
needs the $ for variable substitution). I'm not certain if that's what they
were referring to, but I understand the bytecode compiler concerns about
commands invoking expr recursively.

This is actually one reason I proposed $(...) in the first place - to
provide expression substitution at the language level so that commands like
lseq wouldn't need to handle naked expressions themselves. Let the
parser/compiler handle it once, properly, rather than having individual
commands invoke expr recursively.

Additionally, the naked expression feature in lseq has other issues that
may lead to it being deprecated, which further argues for a language-level
solution.

Best regards,
Eric


On Fri, Oct 31, 2025 at 8:18 AM Donal Fellows <
don...@ma...> wrote:

>
> Someone said (and I've lost track of who; thanks, Outlook!):
> ​
> lrange ... X*2-1 (end-1)/2
> ​
>
> Please don't. That makes producing nice bytecode really awkward. That we
> did something like that with *lseq* is bad enough; the bytecode engine
> has to recursively call itself to handle that and that's just terrible.
> (Fortunately, it's not used so much.)
>
> Donal.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>