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

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

Donald:
Donal:

Thanks for the feedback! I appreciate both perspectives on this.

Both approaches have merit. $= avoids compatibility issues entirely, while
$(...) is more intuitive and has shell precedent. I've implemented both -
happy to go with whatever the core team decides.

Donald's suggestion of using a non-conflicting character would allow the
feature to go directly into 9.x without any compatibility concerns or
pragma mechanism. On the other hand, Donal's preference for $(...)
maintains the cleaner syntax with shell familiarity, and the pragma
approach provides a reasonable migration path for the empty array edge case.

If it would be helpful, I could set up the implementation with compile-time
options to support both mechanisms simultaneously, making it easy to test
and compare both approaches.

Either way, I'm ready to move forward with whichever direction the team
feels is best for Tcl.


Eric


On Tue, Oct 21, 2025 at 2:18 PM Donal Fellows <
don...@ma...> wrote:

> 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.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>