Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[Donal F. <don...@ma...>]

We can match all sorts of things. What matters is what we should match. What is in play is how much of a syntactic incompatibility we are willing to stomach. If we decide that we are rejecting any syntax changes that could possibly have a compatibility impact, we have only the option to reject all change.

The key thing that we are looking for here is to be a syntactic alternative for [expr {expression...}], which has many potential uses. The option with {=} has the disadvantage of not being naturally bracketed unless written as {=}{expression...} and that's just not the nicest thing (for {*}, we were dealing with reinterpretation of words, with the freedom and restrictions that implies, but that's not in play here), and gets ugly when used in the interior of a word. The options with $(expression...) and $((expression...)) are much less of a problem in that regard... but have more potential for compatibility problems. (These are non-theoretical issues for the $(expression...) form, which is definitely in use in the wild; we have found many examples, even if we've not yet worked out if they're truly a problem in all cases.)

Exactly which code should be adapted once we decide what the language change should be... is just a simple matter of changing what needs changing. In terms of commands affected, I can predict this will have an impact inside subst primarily, and possibly assemble; I see no need to add it to the expression language.

Note of course that expressions are expected to syntactically have balanced parentheses (except for comments).

Donal.

-------- Original message --------
From: Florent Merlet <flo...@gm...>
Date: 21/10/2025 20:01 (GMT+00:00)
To: tc...@ro...
Cc: tcl...@li...
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

Why not ? {=} can be check in Tcl_ParseToken.