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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

> if {=} is a valid string, does it mean it has ever been used in the code base ?

Wrong question.

The question is, is any string containing “{=}” going to be passed to subst in anyone’s code anywhere in the world. It was safe to use “{*}” at the beginning of a token because that was not legal Tcl. No working code could contain that string, and it was only exposed in the context of actual auditable code.

From: Florent Merlet <flo...@gm...>
Date: Tuesday, October 21, 2025 at 14:57
To: da Silva, Peter J (USA) <pet...@fl...>, tc...@ro... <tc...@ro...>
Cc: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
if {=} is a valid string, does it mean it has ever been used in the code base ? in tcl repro : https: //github. com/search?q=repo%3Atcltk%2Ftcl%20%7B%3D%7D&type=code one occurence in tools/regexpTestLib. tcl => if {[regexp {=} $flags] ==

if {=} is a valid string, does it mean it has ever been used in the code base ?

in tcl repro : https://github.com/search?q=repo%3Atcltk%2Ftcl%20%7B%3D%7D&type=code<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftcl-2520-257B-253D-257D-26type-3Dcode&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=CyfsegsVMbQTM8BUOM3QAFgUyMu6A2qql4-wcgXkTWU&e=>

 one occurence in tools/regexpTestLib.tcl<https://urldefense.us/v2/url?u=https-3A__github.com_tcltk_tcl_blob_a9f6ab7dba8851da58fec404aa3fa4679bac0e93_tools_regexpTestLib.tcl-23L198&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=f_l9v0uAjxDkCoCD983cJCGF1mO5AEgDEvVHYj8xrU0&e=>

=> if {[regexp {=} $flags] == 1} # (false positive)

in tk repro : https://github.com/search?q=repo%3Atcltk%2Ftk%20%7B%3D%7D&type=code<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftk-2520-257B-253D-257D-26type-3Dcode&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=9Me6yTEagX62EN9QV2Qqu-oAyS4V4bOeKRMORRz5fqg&e=>

no occurence

in tcllib repro : https://github.com/search?q=repo%3Atcltk%2Ftcllib%20<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftcllib-2520&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=24_EwvyMubvwYtieY_qXCr60SaMCmKc0ZzDnc3oFAG0&e=>{%3D}&type=code

no occurence

in tklib repro : https://github.com/search?q=repo%3Atcltk%2Ftklib%20<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftklib-2520&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=NfS1Gl9HPof5QLWw5x6P7PK7dpYz48q3bPWrzfg2XuY&e=>{%3D}&type=code

no occurence.

I don't see any breakage there.
Le 21/10/2025 à 21:11, da Silva, Peter J a écrit :
If “{=}” is detected inside tokens this will cause all kinds of breakage that is going to be a lot harder to keep track of than “$(...)”, because right now “{=}” is a valid string in Tcl.

The {*} special case at the beginning of an argument was safe because no valid Tcl code could have {*}... as an element of a list.

From: Florent Merlet <flo...@gm...><mailto:flo...@gm...>
Date: Tuesday, October 21, 2025 at 14:05
To: tc...@ro...<mailto:tc...@ro...> <tc...@ro...><mailto:tc...@ro...>
Cc: tcl...@li...<mailto:tcl...@li...> <tcl...@li...><mailto:tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
Yes you are right, I was wrong, {*} is not implemented into Tcl_ParseToken. There is no need for it. But it can't be the same for an {=} prefix : it should be detected inside tokens. Florent Le 21/10/2025 à 20: 54, EricT a écrit : I don't think

Yes you are right, I was wrong,  {*} is not implemented into Tcl_ParseToken.

There is no need for it.

But it can't be the same for an {=} prefix : it should be detected inside tokens.

Florent

Le 21/10/2025 à 20:54, EricT a écrit :
I don't think you are correct about {*} in a bareword that's not in quotes:

% proc foo args {puts /$args/}
% foo something{*}{1 + 2 + 3}suffix
/something\{*\}\{1 + 2 + 3\}suffix/
% foo something{*}{1+2+3}suffix
/something{*}{1+2+3}suffix/
% foo {*}{1 2 3}
/1 2 3/
% foo {*}"1 2 3"
/1 2 3/
% foo {*}"123"
/123/
In either of the first 2 cases, it is inserting the {*}{...} as simply text, it is not removing the {*} nor the enclosing {...} and then expanding it to a list. However, it does do all those steps in the 3rd - 5th cases because {*} begins the word.

Eric

On Tue, Oct 21, 2025 at 11:37 AM EricT <tw...@gm...<mailto:tw...@gm...>> wrote:
Ok, so from what I can tell, you are saying that your {=} will not substitute if inside of "quotes {=}..." or barewords.

Here's $(expr) today:

(bin) 1 % set foo "abc $(1 + 2 + 3) def"
abc 6 def
(bin) 2 % set foo something$(1 + 2 + 3)
something6
(bin) 3 % string range "abcdef" 1 end-$(3-2)
bcde
(bin) 4 % set n 3
3
(bin) 5 % string range "abcdef" 1 end-$($n-2)
bcde
Can your proposed {=} do this, because [expr] can do it too. And therefore so can $(expr).

Eric

On Tue, Oct 21, 2025 at 11:24 AM Florent Merlet <flo...@gm...<mailto:flo...@gm...>> wrote:
Le 21/10/2025 à 19:16, EricT a écrit :
The code that handles {*} is somewhat simple because it begins at a word boundary only:

% set foo "abc {*}{1 +2 +3}"
abc {*}{1 +2 +3}
% set foo something{*}{1 + 2 + 3}suffix
wrong # args: should be "set varName ?newValue?"

That means that if his {=} code is implemented the same as {*} the above is what you will get.

Your coding experiment shows precisely that {*} doesn't work only at a word boundary.

if {*} were not detected, « set » would not have complained : it would have silently set foo as "something{*}{1 + 2 + 3}suffix"

But, as  {*} has been detected, it then evaluates  something like :

% set foo something1 2 3suffix  # (? to be checked ?)

This gives at least 4 arguments to « set », so you got this error.

That means that if his {=} code is implemented the same as {*}, the interpreter would have computed the expression 1+2+3 and returned the number 6, so that the variable foo would have been set to « something6suffix ».

{*} is ignored only between quotes. This is'nt an error :

% set foo "something{*}{1 + 2 + 3}suffix"

-> something{*}{1 + 2 + 3}suffix

On the other hand, $(expr) works everywhere $var works. That is why it can be implemented in ~100 lines of code.

But again, I may be wrong, I was hoping to hear from  Florent on this.

Eric

On Tue, Oct 21, 2025 at 6:00 AM Zaumseil René via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:
Hello Eric

A solution to the second point is also in the mail from Florent Merlot with extending {=}

The third point is about a radical change with removing the $-sign to access variables, p.e. x=y+a. This is way out of current proposals.

Regards
rene

Von: EricT <tw...@gm...<mailto:tw...@gm...>>
Gesendet: Dienstag, 21. Oktober 2025 14:53
An: Zaumseil René <RZa...@kk...<mailto:RZa...@kk...>>
Cc: tc...@ro...<mailto:tc...@ro...>; tcl...@li...<mailto:tcl...@li...>; et...@ro...<mailto:et...@ro...>
Betreff: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

The main reason for the $(...) syntax is to encourage the use of safer, compiled, expression code. Since it would also be easier to read and write, users would gravitate to its use and automatically get the benefit of braced expr code.

The secondary reason is that many have complained about [expr {}] being, not as clean syntax as they would like for expression handling. So, like $var instead of [set var] a $(...) shorthand for [expr {...}].

I looked at TIP 647, is that the one you really meant, I saw only a discussion on  Tk_ConfigureWidgets().

Can you elaborate on your 3rd point? I don't quite understand.

Eric

On Tue, Oct 21, 2025 at 1:36 AM Zaumseil René via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:
Hello

I currently do not see the benefit of this proposal, except some char less to type.
IMHO expr has some problems or room for enhancements:

  1.  Double evaluation of arguments

Could be solved with a new command with only 1 argument

  1.  Returns only one value

See p.e. tip 647 syntax

  1.  Access to tcl-variables with $-syntax

This would require a new expression parser

  1.  Anything else?

Do the tip 672 solve one of these points?

Regards
rene

Von: EricT <tw...@gm...<mailto:tw...@gm...>>
Gesendet: Freitag, 17. Oktober 2025 23:22
An: tcl...@li...<mailto:tcl...@li...>
Cc: et...@ro...<mailto:et...@ro...>
Betreff: [Ext] [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax

Hello Tcl Core Team,

I have developed a working prototype implementation of TIP 672, which adds the $(expression) syntax as a more intuitive alternative to [expr {expression}].

Repository: https://github.com/rocketship88/tcl-tip-672-prototype<https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=kOgnKtNg5S0p_z-nZS7HAnBrb0GrBKOlYvbsUmtlt7w&e=>

The implementation is minimal, modifying only two files (tclParse.c and tclNamesp.c) with approximately 100 lines of changes. The key modification converts the existing two-way branch in Tcl_ParseVarName to a three-way branch, with the new path handling $(...) by creating a synthetic [expr {...}] command string.

Key Accomplishments:

Full bytecode compilation: The synthetic string approach integrates seamlessly with the existing compiler, producing identical optimized bytecode as [expr {...}]. The disassembler output (shown in the README) demonstrates efficient variable loading with no runtime parsing overhead.

Proven approach: Jim Tcl has used this syntax successfully for years

Comprehensive testing: Works correctly with string interpolation, variable scoping, error handling, and interactive mode

Known Limitations:

Memory leak: The synthetic string is allocated but not tracked for cleanup in Tcl_FreeParse. This requires core team guidance on the preferred solution (modify Tcl_Parse structure vs. thread-local tracking).

Error messages: Currently show the synthetic command rather than the original $(...) syntax, though this is arguably helpful for debugging.

Questions for the Team:

What is the preferred approach for tracking synthetic strings for cleanup?
Is this prototype architecture acceptable for Tcl 9.x?
Are there concerns with the synthetic string approach that I should address?

The complete implementation with side-by-side diffs is available in the repository. I'm happy to refine the code based on your feedback and would appreciate any guidance on moving this forward.

Best regards,
Eric
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>

_______________________________________________

Tcl-Core mailing list

Tcl...@li...<mailto:Tcl...@li...>

https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
--
________________________________
Florent MERLET
4 rue Johann Strauss
Logement 7
86180 BUXEROLLES
________________________________
Mél. : flo...@gm...<mailto:flo...@gm...>
Tél. : 06 70 00 63 48
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
--
________________________________
Florent MERLET
4 rue Johann Strauss
Logement 7
86180 BUXEROLLES
________________________________
Mél. : flo...@gm...<mailto:flo...@gm...>
Tél. : 06 70 00 63 48
--
________________________________
Florent MERLET
4 rue Johann Strauss
Logement 7
86180 BUXEROLLES
________________________________
Mél. : flo...@gm...<mailto:flo...@gm...>
Tél. : 06 70 00 63 48

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

The Tool Command Language implementation

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