tcl-core — Tcl Core Team discussions about Tcl development

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

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

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...>
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...> 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...>
>> *Gesendet:* Dienstag, 21. Oktober 2025 14:53
>> *An:* Zaumseil René <RZa...@kk...>
>> *Cc:* tc...@ro...; tcl...@li...;
>> 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...> 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
>>
>>    2. Returns only one value
>>
>> See p.e. tip 647 syntax
>>
>>    3. Access to tcl-variables with $-syntax
>>
>> This would require a new expression parser
>>
>>    4. Anything else?
>>
>>
>>
>> Do the tip 672 solve one of these points?
>>
>>
>>
>>
>>
>> Regards
>>
>> rene
>>
>>
>>
>> *Von:* EricT <tw...@gm...>
>> *Gesendet:* Freitag, 17. Oktober 2025 23:22
>> *An:* tcl...@li...
>> *Cc:* 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
>>
>> 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...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>
>
> _______________________________________________
> Tcl-Core mailing lis...@li...://lists.sourceforge.net/lists/listinfo/tcl-core
>
> --
> ------------------------------
> *Florent MERLET*
>
>
> *4 rue Johann Strauss Logement 7 86180 BUXEROLLES*
> ------------------------------
> *Mél.* : *flo...@gm... <flo...@gm...>*
> *Tél.* : *06 70 00 63 48*
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

[da S. P. J <pet...@fl...>]

No, that error is because the spaces in “set foo something{*}{1 + 2 + 3}suffix” were interpreted before “{*}” would even have been considered.

The arguments to set in that case are:

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


From: Florent Merlet <flo...@gm...>
Date: Tuesday, October 21, 2025 at 13:24
To: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
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

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=uzKH4hlQZ_k-_YWuVjU4ztQovVeAnil8nvhs2l-GlFd7CkfK4-CHuqb8UmHe46fP&s=lw6bJuHgl9a55KQ0wg5rkmIKIHFEn44L5uMkQhVmq-Y&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=uzKH4hlQZ_k-_YWuVjU4ztQovVeAnil8nvhs2l-GlFd7CkfK4-CHuqb8UmHe46fP&s=r4JuJZ7ly1-tsryKo0BXikrNbc0hmSO4E1WGB_3drRg&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=uzKH4hlQZ_k-_YWuVjU4ztQovVeAnil8nvhs2l-GlFd7CkfK4-CHuqb8UmHe46fP&s=r4JuJZ7ly1-tsryKo0BXikrNbc0hmSO4E1WGB_3drRg&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=uzKH4hlQZ_k-_YWuVjU4ztQovVeAnil8nvhs2l-GlFd7CkfK4-CHuqb8UmHe46fP&s=r4JuJZ7ly1-tsryKo0BXikrNbc0hmSO4E1WGB_3drRg&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

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

[Florent M. <flo...@gm...>]

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...> 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...>
>     *Gesendet:* Dienstag, 21. Oktober 2025 14:53
>     *An:* Zaumseil René <RZa...@kk...>
>     *Cc:* tc...@ro...; tcl...@li...;
>     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...> 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
>
>          2. Returns only one value
>
>         See p.e. tip 647 syntax
>
>          3. Access to tcl-variables with $-syntax
>
>         This would require a new expression parser
>
>          4. Anything else?
>
>         Do the tip 672 solve one of these points?
>
>         Regards
>
>         rene
>
>         *Von:*EricT <tw...@gm...>
>         *Gesendet:* Freitag, 17. Oktober 2025 23:22
>         *An:* tcl...@li...
>         *Cc:* 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
>
>         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...
>         https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>     _______________________________________________
>     Tcl-Core mailing list
>     Tcl...@li...
>     https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
-- 
------------------------------------------------------------------------
*Florent MERLET*
/4 rue Johann Strauss
Logement 7
86180 BUXEROLLES/
------------------------------------------------------------------------
*Mél.* : /flo...@gm.../
*Tél.* : /06 70 00 63 48/

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

[da S. P. J <pet...@fl...>]

{*} always comes at the start of a new argument.

[expr...] could come anywhere in a string passed to subst, so there is no guard against a random {=}{ sequence inside a string, which is currently completely valid TCL and much harder to find, especially in encoded strings. I don’t think it’s a viable option.

From: Colin Macleod via Tcl-Core <tcl...@li...>
Date: Monday, October 20, 2025 at 11:32
To: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax
I would say {=}{expression} is more Tcl-ish, though two characters longer. It follows the precedent of {*}, and avoids the incompatibility of $(expression). I wonder if that could also be implemented by a simple macro-type substitution at the


I would say {=}{expression} is more Tcl-ish, though two characters longer.  It follows the precedent of {*}, and avoids the incompatibility of $(expression).  I wonder if that could also be implemented by a simple macro-type substitution at the parsing stage, as Eric has proposed.  If {=} was TIP-ed I would happily withdraw my competing TIP 676.

Colin.
On 20/10/2025 16:11, da Silva, Peter J wrote:
Obviously I think this is a great idea and I think anyone who actually uses $(thing) in production code is crazy, but when I brought it up it got shot down because it was apparently found in the wild in production code.

Pity it didn’t get into 9.0 :) but this would be a good era to do it in.

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

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

Rene:

Unless I'm mistaken, the approach by Florent is to treat {=} in the same
way as {*}, at least that's what he said in his last message to me. If that
is how he would approach it, then it would not substitute inside of quoted
strings or barewords.

I may be wrong on this, but he hasn't replied to my question about being
able to do so.

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.

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...> 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...>
> *Gesendet:* Dienstag, 21. Oktober 2025 14:53
> *An:* Zaumseil René <RZa...@kk...>
> *Cc:* tc...@ro...; tcl...@li...;
> 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...> 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
>
>    2. Returns only one value
>
> See p.e. tip 647 syntax
>
>    3. Access to tcl-variables with $-syntax
>
> This would require a new expression parser
>
>    4. Anything else?
>
>
>
> Do the tip 672 solve one of these points?
>
>
>
>
>
> Regards
>
> rene
>
>
>
> *Von:* EricT <tw...@gm...>
> *Gesendet:* Freitag, 17. Oktober 2025 23:22
> *An:* tcl...@li...
> *Cc:* 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
>
> 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...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

Jan:

Thanks for the support and looking at a knob.

This is exactly the approach I was hoping for - an interpreter-bound knob
for opt-in in 9.1, with a path to default in 10. I really appreciate you
taking this on.

I'm working on expanding the test suite with comprehensive edge cases to
ensure the implementation is solid. I'll have an updated subexpr.test file
ready soon that can be dropped into the test directory.

Regarding subst and $(, I'd be interested to hear your thoughts on any
options that might help there.
Eric

On Tue, Oct 21, 2025 at 6:42 AM Jan Nijtmans <jan...@gm...> wrote:

> Op ma 20 okt 2025 om 22:59 schreef EricT:
>
>> There is one other edge case with $(expr): the subst command currently treats it as variable substitution. This means:
>> subst -nocommands {$(expr)}    # Doesn't work - still substitutessubst -novariables {$(expr)}   # Works - suppresses substitution
>>
>>
> Good catch !     How about adding a "subst -noexpr"?   It works almost the
> same
> as "subst -novariables", but whether it substitutes depends on whether '$'
> is
> followed by '(' or not. That shouldn't be too difficult to implement.
>
> Regards,
>         Jan Nijtmans
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

[Florent M. <flo...@gm...>]

Jan,

Mathematical expression shorthand has been a long term debate, but 
consensus has never emerged on this subject.

But, the fact is that the $(...) syntax is breaking code, but the {=} 
syntax is not.

Moreover, the concept of word prefix, to modulate interpretation of 
words, is a room for many improvements, in a backward compatible way. 
One of this improvement is the multiline or inline comments prefix {#}.

So, why prefer a syntax that is breaking code, when it exits an 
alternative syntax that is not breaking any code ?

Is it to make people to go far away from Tcl ?


Le 21/10/2025 à 15:28, Jan Nijtmans a écrit :
> Op di 21 okt 2025 om 14:53 schreef EricT:
>> 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.
> I think the best way forward is simply to go for the $(...) syntax, as
> proposed now in the TIP. Just make it an opt-in feature in Tcl 9.1, and
> deprecate the use of empty-string array variables in $-substitutions
> (but keep everything as-is for 'set'). I'll try to implement some
> interpreter-bound knob (I think that's better than a global knob)
>
> That opens the way to make this behavior the default in Tcl 10....
>
> Thanks!
>           Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
-- 
------------------------------------------------------------------------
*Florent MERLET*
/4 rue Johann Strauss
Logement 7
86180 BUXEROLLES/
------------------------------------------------------------------------
*Mél.* : /flo...@gm.../
*Tél.* : /06 70 00 63 48/

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

[Jan N. <jan...@gm...>]

Op ma 20 okt 2025 om 22:59 schreef EricT:

> There is one other edge case with $(expr): the subst command currently treats it as variable substitution. This means:
> subst -nocommands {$(expr)}    # Doesn't work - still substitutessubst -novariables {$(expr)}   # Works - suppresses substitution
>
>
Good catch !     How about adding a "subst -noexpr"?   It works almost the
same
as "subst -novariables", but whether it substitutes depends on whether '$'
is
followed by '(' or not. That shouldn't be too difficult to implement.

Regards,
        Jan Nijtmans

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

[Jan N. <jan...@gm...>]

Op di 21 okt 2025 om 14:53 schreef EricT:
>
> 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.

I think the best way forward is simply to go for the $(...) syntax, as
proposed now in the TIP. Just make it an opt-in feature in Tcl 9.1, and
deprecate the use of empty-string array variables in $-substitutions
(but keep everything as-is for 'set'). I'll try to implement some
interpreter-bound knob (I think that's better than a global knob)

That opens the way to make this behavior the default in Tcl 10....

Thanks!
         Jan Nijtmans

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

[Zaumseil R. <RZa...@kk...>]

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...>
Gesendet: Dienstag, 21. Oktober 2025 14:53
An: Zaumseil René <RZa...@kk...>
Cc: tc...@ro...; tcl...@li...; 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

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

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

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

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...> 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
>
>    2. Returns only one value
>
> See p.e. tip 647 syntax
>
>    3. Access to tcl-variables with $-syntax
>
> This would require a new expression parser
>
>    4. Anything else?
>
>
>
> Do the tip 672 solve one of these points?
>
>
>
>
>
> Regards
>
> rene
>
>
>
> *Von:* EricT <tw...@gm...>
> *Gesendet:* Freitag, 17. Oktober 2025 23:22
> *An:* tcl...@li...
> *Cc:* 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
>
> 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...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

Hi Donal:

Yes, I should have been more careful with that. I see that it is actually
$((...)) in bash.

I think the best approach is to find all the uses by both searching and
also a pragma that optionally will cause any use of $() to be flagged with
an error. Then convert to using one of the two alternative methods.

I understand empty array names exist in production code. It's also
important to note that ${()} doesn't work for all cases - it only handles
literal indices. When the index involves variable substitution (like
$($var)), users must use [set (...)] instead.

The migration path is clear I believe: use [set (...)] which works for all
cases, both before and after the feature is enabled.
Thanks again for the feedback.

Eric


On Tue, Oct 21, 2025 at 1:55 AM Donal Fellows <
don...@ma...> wrote:

> ​
> EricT
> 2025-10-21 04:12
> 1. Shell precedent: The $(command) syntax is well-established in bash/sh
> for command substitution. Tcl users familiar with shell scripting would
> find this natural, not confusing.
> ​
> Surely the better shell precedent would be the $((expression)) form? That
> would also be quite a bit less likely to clash with existing use cases. Hmm,
> a quick search with
> https://github.com/search?q=%24%28%28+language%3ATcl&type=code gives 29
> hits (most of which appear to be false positives; the real hits seem to be
> from one place in JimTcl itself), as opposed to 4k hits when looking for $(
> in Tcl code; two orders of magnitude less usage. One of the *really* nice
> things about a resource like GitHub is that one can *quickly* search for
> language syntax features across a lot of code and get a good feeling for
> practical compatibility.
>
> While $(([llength $x] - 17)) is no shorter than {=}{[llength $x] - 17},
> it's definitely easier to type!
>
> (Eric: Don't lose heart! These discussions are a *lot* less acrimonious
> than the discussion over what became {*} was.)
>
> Donal.
>
> ------------------------------
> *From:* EricT <tw...@gm...>
> *Sent:* Tuesday, October 21, 2025 04:11
> *To:* Brian Griffin <bri...@ea...>
> *Cc:* tc...@ro... <tc...@ro...>; Tcl Core List <
> tcl...@li...>
> *Subject:* Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr)
> Syntax
>
> Thanks for the feedback, Brian! I understand your concern about the
> semantic distinction between $ (value) and [ ] (execution).
>
> I'd offer a few thoughts:
>
> 1. Shell precedent: The $(command) syntax is well-established in bash/sh
> for command substitution. Tcl users familiar with shell scripting would
> find this natural, not confusing.
>
> 2. $ already involves execution: Even $var involves command execution
> internally (TclGetVar), it's just optimized. The distinction between "value
> substitution" and "command execution" is somewhat artificial at the
> implementation level.
>
> 3.  expr is special and has historical precedent: Unlike arbitrary
> commands, expr is used so frequently that syntactic sugar makes sense -
> similar to how $var is sugar for [set var]. We optimize the common case. I
> believe there was a time in early Tcl before $var existed when [set var]
> was the only choice - if so, adding $var as syntactic sugar for variable
> substitution was a usability win. $(expr) follows the same pattern - sugar
> for the extremely common [expr {...}] case.
>
> 4. Consistency: $(expr) fits the pattern of "$ means substitute something
> here" - whether a variable, array element, or expression result. Modern
> languages like Python have embraced similar concepts with f-strings that
> allow {expression} for inline evaluation. $(expr) brings this convenience
> to Tcl while maintaining our substitution semantics.
>
> That said, I appreciate the philosophical consistency argument. Do you see
> the security benefits (auto-bracing) as compelling enough to outweigh the
> semantic concern?
>
> Did you see the email I sent you about lseq? Maybe it landed in your spam
> folder - that happened once before as I recall.
>
> Eric
>
>
> On Mon, Oct 20, 2025 at 7:19 PM Brian Griffin <bri...@ea...>
> wrote:
>
> I like the idea of simplifying expression substitutions.  The problem I
> have is that the '$' is defined to be a value substitution. Running a
> command (execution) is a [] substitution, not a '$' substitution.
> Conflating the two modes of substitution can cause confusion for newbies,
> and even experienced programmers.
>
> I recognize that this view is a very subtle distinction, but I think it's
> important.
>
> Think of it like conflating * vs & in C.  (Maybe not that bad, but similar)
>
> -Brian
>
> On Oct 20, 2025, at 07:22, EricT <tw...@gm...> wrote:
>
> Regarding the discussion in the telco today. If the incompatibility
> discussed is the known empty array issue, then for that I would propose the
> following:
>
> There could be a pragma or tcl_dollar_expr global variable with several
> settings.
>
> 1. Work in compatibility mode, i.e. as though the feature was not
> implemented at all.
> 2. Work in diagnostic mode, throw an error for any $(...) use
> 3. Work in full implementation mode
>
> The code to do this, given a global C variable to check would be trivial.
>
> This value could default to 1. for at least 9.1 or 9.2 but there could be
> an option, similar to tclsh -encoding, that would allow the pragma variable
> to be set before any init script code is run. This would give developers
> the opportunity to set the variable to mode 2 in order to easily track down
> uses of $(index) before any code were to begin using $(expr).
>
> I think it would be quite rare if this syntax change would affect binary
> extensions, so it should be only with script level coding.
>
> The fix to any code that is using the empty array variable, is to change
> from,
>
>     set val $(index)
>     set val $($var)  - or any other valid index string
>
> to
>
>    set val ${(index)}
>    set val ${($var)}
>
> Likewise for any other use of the $(...) substitution in current use.
>
> This change can begin to be made right away, since it is a
> compatible syntax that does not change the semantics.  Once all the init
> time script code or packages that use the un-braced syntax are found and
> changed, the feature could begin to be used by those who are interested.
>
> On the other hand, if the incompatibility is something other than this
> empty array, I'd be most appreciative to know what it is.
>
> thanks
>
> Eric
>
>
> On Sun, Oct 19, 2025 at 3:44 AM EricT <tw...@gm...> wrote:
>
> Harald,
>
> Thank you for your willingness to sponsor!
>
> To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl user
> who, in retirement, wanted to give something back to the Tcl community. Jim
> Tcl's successful use of this syntax for years demonstrates that the concept
> is viable.
>
> Regarding the telco: I attempted to join previously but was unsuccessful
> with the setup. I won't be able to participate on Monday, but I'm available
> via email for any questions or clarifications that arise from the
> discussion.
>
> I don't currently have write access to either the Tcl Fossil repository or
> the TIP repository, so I'm unable to make changes directly. At nearly 80
> years old, I'm not comfortable learning new version control systems on my
> own. If the TIP moves forward, I'd need guidance and assistance with the
> Fossil workflow, or perhaps someone from the core team who shares our
> interest in this TIP could handle the integration based on my GitHub
> prototype.
>
> I'm currently developing a comprehensive test suite in standard tcltest
> format, with particular focus on edge cases.
>
> Looking forward to hearing how Monday's discussion goes!
>
> Best regards,
> Eric
>
>
> On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <
> har...@el...> wrote:
>
> Eric,
> sponsoring is no problem. The point is to get positive votes.
> This requires a positive discussion.
> You are the Author of Jim?
> Could you participate on the telco on Monday?
>
> Do you have write access to the tcl fossil? We would need the
> implementation there.
>
> Thanks for all,
> Harald
>
> Am 18.10.2025 um 22:58 schrieb EricT:
> > Thank you for the positive feedback and for raising this in Monday's
> > telco! I'm encouraged by your support.
> >
> > Regarding $(a) - you're right that reading an empty array element with a
> > variable index is a valid construct. However, this is explicitly
> > addressed in the TIP and the repository README. The workarounds are
> > straightforward:
> >
> >    ${(a)}        # Braced form
> >    [set (a)]     # Command substitution
> >
> > Both still work. In fact, code using $(varname) could be proactively
> > modified to use ${(varname)} to indicate the clear intent of an empty
> > array reference, which improves readability. The security, performance,
> > and usability benefits of $(...) seemed to justify this trade-off for
> > Tcl 9.x where some incompatibilities are expected.
> >
> > Given your interest in the feature, would you be willing to consider
> > sponsoring TIP 672? The implementation is working and minimal (~100
> > lines across two files), with the main open question being the preferred
> > approach for tracking synthetic strings for cleanup. Your guidance on
> > that architectural decision would be particularly valuable.
> >
> > The prototype repository with full implementation and examples is here:
> >
> > https://github.com/rocketship88/tcl-tip-672-prototype [github.com]
> <https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>
>  <https://
> > github.com/rocketship88/tcl-tip-672-prototype [github.com]
> <https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>
> >
> >
> > Looking forward to the results of the discussion on Monday! I won't be
> > able to join the telco discussion, but I'm available via email for any
> > questions or clarifications that arise.
> >
> >
> > On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann
> > <har...@el... <mailto:har...@el...>>
> wrote:
> >
> >     Am 17.10.2025 um 23:22 schrieb EricT:
> >      > 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
> [github.com]
> <https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>
> >     <https://github.com/rocketship88/tcl-tip-672-prototype [github.com]
> <https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>
> >
> >      > <https://github.com/rocketship88/tcl-tip-672-prototype
> [github.com]
> <https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>
>  <https://
> >     github.com/rocketship88/tcl-tip-672-prototype [github.com]
> <https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>
> >>
> >      >
> >      > 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
> >     Eric,
> >     great proposal, thank you !
> >
> >     Perhaps, we may discuss this on Monday in the biweekly telco.
> >     I am also excited and in favor to this.
> >     Nevertheless, "$(a)" is to my knowledge a quite common syntax for
> >     arrays. We have already killed less disruptive proposals (see
> optional
> >     "- args") by endless discussions and getting nowhere.
> >     Hope, this will be fruitful.
> >
> >     In addition, I would like to add the Tk test reform by the other
> >     Eric to
> >     the biweekly topics.
> >     Here is a revised agenda proposal proposal:
> >
> >     Top 1) Release calender (TIP 713)
> >     - 9.0.3: October (2 weeks left)
> >     - 9.1a1: November (6 weeks left)
> >     Top 2) TIP 734 nested mutex (go or not)
> >     Top 3) TIP 733: accessability (test status)
> >     Top 4) TIP 732: TCL library path (discussion)
> >     Top 5) TIP 731: use C enums (no brainer?)
> >     Top 6) TIP 720: new bytecodes (final, great! Any issues?)
> >     Top 7) TIP 721: Tcl_AttemptGetString
> >     Top 8) TIP 715: supported build systems
> >     Top 9) $($a+$b) syntax for expressions
> >     Top 10) Tk test reform by Eric (Thanks !)
> >     Top 11) Tcl depot and awthemes ?
> >     Top 12) AOB
> >     Top 13) Next meeting:
> >           3rd of November 12:00 UTC.
> >           Daytime saving time ends 2nd of November in US, 26th of
> >     October in
> >     Europe.
> >           Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?
> >
> >     Take care,
> >     Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> [lists.sourceforge.net]
> <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> [lists.sourceforge.net]
> <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> [lists.sourceforge.net]
> <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] CFV Warning - TIP 733

[Kevin W. <kw...@co...>]

Checking for the existence of the check_screenreader command via "info 
commands" allowed a child interp to load cleanly. I did not see a 
failure on this issue in the test suite, so I've committed the update 
with the expectation that the test suite will now pass.

This also appears to mean that accessibility cannot run in a child 
interp, because the absence of the command check_screenreader command 
means accessibility will not load. Is that a problem? I'm fine 
documenting it in the TIP and/or man page. Please advise.

On 10/21/25 7:47 AM, Kevin Walzer wrote:
> This is an area I don't really work with, so I don't understand what 
> is going on. Why wouldn't a command that is available in the main 
> interp fail to be available in a child interp that was not called with 
> the -safe flag? I understand there's probably some machinery here I'm 
> not wiring up - any suggestions? 

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

[Florent M. <flo...@gm...>]

Hi,
Why should we allways use braces after {=} prefix ? The prefixed word will
finish to the next space.

So we can write simply :

{=}[llength $x]-17

Instead of:

{=}{[llength $x] - 17}


Most of {=} prefix use case won't need extra bracing.

To address the multiple return of value, just use "coma outside fonction"
error, to return a list :

i.e :

.c create line {=}{
      $O(x)+$X1*$scale(x),
      $O(y)+$Y1*$scale(y),
      $O(x)+$X2*$scale(x),
      $O(y)+$Y2*$scale(y)
}

FM

Re: [TCLCORE] CFV Warning - TIP 733

[Kevin W. <kw...@co...>]

I was able to reproduce this just interactively in Wish. The failure 
occurs when the "interp create" command is run:

% interp create foo
foo
% foo eval {
load {} Tk
}
Can't find a usable tk.tcl in the following directories:
/Library/Frameworks/Tk.framework/Versions/9.1/Resources/Scripts

/Library/Frameworks/Tk.framework/Versions/9.1/Resources/Scripts/tk.tcl: 
invalid command name "::tk::accessible::check_screenreader"
invalid command name "::tk::accessible::check_screenreader"
     while executing
"::tk::accessible::check_screenreader"

...

This is an area I don't really work with, so I don't understand what is 
going on. Why wouldn't a command that is available in the main interp 
fail to be available in a child interp that was not called with the 
-safe flag? I understand there's probably some machinery here I'm not 
wiring up - any suggestions?

On 10/21/25 6:50 AM, Kevin Walzer wrote:
> This is where I am unsure how to proceed. The check_screenreader command is either a stub (if Tk is built without accessibility on Linux) or a full command, but in either case it should be present. This looks instead like some kind of timing issue instead with the test suite.  I can’t load accessibility any earlier. Can anyone suggest a solution?
>
>> On Oct 21, 2025, at 3:45 AM, Jan Nijtmans <jan...@gm...> wrote:
>>
>> Op za 18 okt 2025 om 23:07 schreef Kevin Walzer:
>>> 2. Jan noted that the test suite failed on all three platforms during
>>> automated Github runs. I added code to accessibility.tcl to return an
>>> empty namespace if a screen reader isn't running. That way there will be
>>> no unintended side effects from the accessibility commands conflicting
>>> with the test suite, which  now runs normally on all three platforms.
>>> Note: I am NOT including automated testing of accessibility within the
>>> test suite itself. Accessibility is best tested through interactive use
>>> of a screen reader.
>> Unfortunately, testcases are still failing when there is no
>>     screen-reader. e.g.:
>>     ==== font-1.1 TkFontPkgInit FAILED
>>     ==== Contents of test case:
>>     interp create foo
>>     foo eval {
>>     load {} Tk
>>     ....
>>     invalid command name "::tk::accessible::check_screenreader"
>>     while executing
>>     "::tk::accessible::check_screenreader"
>>     invoked from within
>>     "if {([::tk::accessible::check_screenreader] eq 0 ||
>> [::tk::accessible::check_screenreader] eq "")} {
>>     # Do not load if screen reader is not running..."
>>     (file "/Users/runner/work/tk/tk/tk/library/accessibility.tcl" line 14)
>>     invoked from within
>>
>> <https://github.com/tcltk/tk/actions/runs/18675529789/job/5324461262>
>>
>> This is on Linux. but Windows and MacOS fail too
>>
>> :-(
>>     Jan Nijtmans
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV Warning - TIP 733

[Kevin W. <kw...@co...>]

This is where I am unsure how to proceed. The check_screenreader command is either a stub (if Tk is built without accessibility on Linux) or a full command, but in either case it should be present. This looks instead like some kind of timing issue instead with the test suite.  I can’t load accessibility any earlier. Can anyone suggest a solution?

> On Oct 21, 2025, at 3:45 AM, Jan Nijtmans <jan...@gm...> wrote:
> 
> Op za 18 okt 2025 om 23:07 schreef Kevin Walzer:
>> 2. Jan noted that the test suite failed on all three platforms during
>> automated Github runs. I added code to accessibility.tcl to return an
>> empty namespace if a screen reader isn't running. That way there will be
>> no unintended side effects from the accessibility commands conflicting
>> with the test suite, which  now runs normally on all three platforms.
>> Note: I am NOT including automated testing of accessibility within the
>> test suite itself. Accessibility is best tested through interactive use
>> of a screen reader.
> 
> Unfortunately, testcases are still failing when there is no
>    screen-reader. e.g.:
>    ==== font-1.1 TkFontPkgInit FAILED
>    ==== Contents of test case:
>    interp create foo
>    foo eval {
>    load {} Tk
>    ....
>    invalid command name "::tk::accessible::check_screenreader"
>    while executing
>    "::tk::accessible::check_screenreader"
>    invoked from within
>    "if {([::tk::accessible::check_screenreader] eq 0 ||
> [::tk::accessible::check_screenreader] eq "")} {
>    # Do not load if screen reader is not running..."
>    (file "/Users/runner/work/tk/tk/tk/library/accessibility.tcl" line 14)
>    invoked from within
> 
> <https://github.com/tcltk/tk/actions/runs/18675529789/job/5324461262>
> 
> This is on Linux. but Windows and MacOS fail too
> 
> :-(
>    Jan Nijtmans

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

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

​
EricT
2025-10-21 04:12
1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.
​
Surely the better shell precedent would be the $((expression)) form? That would also be quite a bit less likely to clash with existing use cases. Hmm, a quick search with https://github.com/search?q=%24%28%28+language%3ATcl&type=code gives 29 hits (most of which appear to be false positives; the real hits seem to be from one place in JimTcl itself), as opposed to 4k hits when looking for $( in Tcl code; two orders of magnitude less usage. One of the really nice things about a resource like GitHub is that one can quickly search for language syntax features across a lot of code and get a good feeling for practical compatibility.

While $(([llength $x] - 17)) is no shorter than {=}{[llength $x] - 17}, it's definitely easier to type!

(Eric: Don't lose heart! These discussions are a lot less acrimonious than the discussion over what became {*} was.)

Donal.

________________________________
From: EricT <tw...@gm...>
Sent: Tuesday, October 21, 2025 04:11
To: Brian Griffin <bri...@ea...>
Cc: tc...@ro... <tc...@ro...>; Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax

Thanks for the feedback, Brian! I understand your concern about the semantic distinction between $ (value) and [ ] (execution).

I'd offer a few thoughts:

1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.

2. $ already involves execution: Even $var involves command execution internally (TclGetVar), it's just optimized. The distinction between "value substitution" and "command execution" is somewhat artificial at the implementation level.

3.  expr is special and has historical precedent: Unlike arbitrary commands, expr is used so frequently that syntactic sugar makes sense - similar to how $var is sugar for [set var]. We optimize the common case. I believe there was a time in early Tcl before $var existed when [set var] was the only choice - if so, adding $var as syntactic sugar for variable substitution was a usability win. $(expr) follows the same pattern - sugar for the extremely common [expr {...}] case.

4. Consistency: $(expr) fits the pattern of "$ means substitute something here" - whether a variable, array element, or expression result. Modern languages like Python have embraced similar concepts with f-strings that allow {expression} for inline evaluation. $(expr) brings this convenience to Tcl while maintaining our substitution semantics.

That said, I appreciate the philosophical consistency argument. Do you see the security benefits (auto-bracing) as compelling enough to outweigh the semantic concern?

Did you see the email I sent you about lseq? Maybe it landed in your spam folder - that happened once before as I recall.

Eric


On Mon, Oct 20, 2025 at 7:19 PM Brian Griffin <bri...@ea...<mailto:bri...@ea...>> wrote:
I like the idea of simplifying expression substitutions.  The problem I have is that the '$' is defined to be a value substitution. Running a command (execution) is a [] substitution, not a '$' substitution.  Conflating the two modes of substitution can cause confusion for newbies, and even experienced programmers.

I recognize that this view is a very subtle distinction, but I think it's important.

Think of it like conflating * vs & in C.  (Maybe not that bad, but similar)

-Brian

On Oct 20, 2025, at 07:22, EricT <tw...@gm...<mailto:tw...@gm...>> wrote:

Regarding the discussion in the telco today. If the incompatibility discussed is the known empty array issue, then for that I would propose the following:

There could be a pragma or tcl_dollar_expr global variable with several settings.

1. Work in compatibility mode, i.e. as though the feature was not implemented at all.
2. Work in diagnostic mode, throw an error for any $(...) use
3. Work in full implementation mode

The code to do this, given a global C variable to check would be trivial.

This value could default to 1. for at least 9.1 or 9.2 but there could be an option, similar to tclsh -encoding, that would allow the pragma variable to be set before any init script code is run. This would give developers the opportunity to set the variable to mode 2 in order to easily track down uses of $(index) before any code were to begin using $(expr).

I think it would be quite rare if this syntax change would affect binary extensions, so it should be only with script level coding.

The fix to any code that is using the empty array variable, is to change from,

    set val $(index)
    set val $($var)  - or any other valid index string

to

   set val ${(index)}
   set val ${($var)}

Likewise for any other use of the $(...) substitution in current use.

This change can begin to be made right away, since it is a compatible syntax that does not change the semantics.  Once all the init time script code or packages that use the un-braced syntax are found and changed, the feature could begin to be used by those who are interested.

On the other hand, if the incompatibility is something other than this empty array, I'd be most appreciative to know what it is.

thanks

Eric


On Sun, Oct 19, 2025 at 3:44 AM EricT <tw...@gm...<mailto:tw...@gm...>> wrote:
Harald,

Thank you for your willingness to sponsor!

To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl user who, in retirement, wanted to give something back to the Tcl community. Jim Tcl's successful use of this syntax for years demonstrates that the concept is viable.

Regarding the telco: I attempted to join previously but was unsuccessful with the setup. I won't be able to participate on Monday, but I'm available via email for any questions or clarifications that arise from the discussion.

I don't currently have write access to either the Tcl Fossil repository or the TIP repository, so I'm unable to make changes directly. At nearly 80 years old, I'm not comfortable learning new version control systems on my own. If the TIP moves forward, I'd need guidance and assistance with the Fossil workflow, or perhaps someone from the core team who shares our interest in this TIP could handle the integration based on my GitHub prototype.

I'm currently developing a comprehensive test suite in standard tcltest format, with particular focus on edge cases.

Looking forward to hearing how Monday's discussion goes!

Best regards,
Eric


On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <har...@el...<mailto:har...@el...>> wrote:
Eric,
sponsoring is no problem. The point is to get positive votes.
This requires a positive discussion.
You are the Author of Jim?
Could you participate on the telco on Monday?

Do you have write access to the tcl fossil? We would need the
implementation there.

Thanks for all,
Harald

Am 18.10.2025 um 22:58 schrieb EricT:
> Thank you for the positive feedback and for raising this in Monday's
> telco! I'm encouraged by your support.
>
> Regarding $(a) - you're right that reading an empty array element with a
> variable index is a valid construct. However, this is explicitly
> addressed in the TIP and the repository README. The workarounds are
> straightforward:
>
>    ${(a)}        # Braced form
>    [set (a)]     # Command substitution
>
> Both still work. In fact, code using $(varname) could be proactively
> modified to use ${(varname)} to indicate the clear intent of an empty
> array reference, which improves readability. The security, performance,
> and usability benefits of $(...) seemed to justify this trade-off for
> Tcl 9.x where some incompatibilities are expected.
>
> Given your interest in the feature, would you be willing to consider
> sponsoring TIP 672? The implementation is working and minimal (~100
> lines across two files), with the main open question being the preferred
> approach for tracking synthetic strings for cleanup. Your guidance on
> that architectural decision would be particularly valuable.
>
> The prototype repository with full implementation and examples is here:
>
> https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$> <https://
> github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>>
>
> Looking forward to the results of the discussion on Monday! I won't be
> able to join the telco discussion, but I'm available via email for any
> questions or clarifications that arise.
>
>
> On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann
> <har...@el...<mailto:har...@el...> <mailto:har...@el...<mailto:har...@el...>>> wrote:
>
>     Am 17.10.2025 um 23:22 schrieb EricT:
>      > 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 [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>
>     <https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>>
>      > <https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$> <https://
>     github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>>>
>      >
>      > 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
>     Eric,
>     great proposal, thank you !
>
>     Perhaps, we may discuss this on Monday in the biweekly telco.
>     I am also excited and in favor to this.
>     Nevertheless, "$(a)" is to my knowledge a quite common syntax for
>     arrays. We have already killed less disruptive proposals (see optional
>     "- args") by endless discussions and getting nowhere.
>     Hope, this will be fruitful.
>
>     In addition, I would like to add the Tk test reform by the other
>     Eric to
>     the biweekly topics.
>     Here is a revised agenda proposal proposal:
>
>     Top 1) Release calender (TIP 713)
>     - 9.0.3: October (2 weeks left)
>     - 9.1a1: November (6 weeks left)
>     Top 2) TIP 734 nested mutex (go or not)
>     Top 3) TIP 733: accessability (test status)
>     Top 4) TIP 732: TCL library path (discussion)
>     Top 5) TIP 731: use C enums (no brainer?)
>     Top 6) TIP 720: new bytecodes (final, great! Any issues?)
>     Top 7) TIP 721: Tcl_AttemptGetString
>     Top 8) TIP 715: supported build systems
>     Top 9) $($a+$b) syntax for expressions
>     Top 10) Tk test reform by Eric (Thanks !)
>     Top 11) Tcl depot and awthemes ?
>     Top 12) AOB
>     Top 13) Next meeting:
>           3rd of November 12:00 UTC.
>           Daytime saving time ends 2nd of November in US, 26th of
>     October in
>     Europe.
>           Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?
>
>     Take care,
>     Harald
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>

_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>

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

[Zaumseil R. <RZa...@kk...>]

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...>
Gesendet: Freitag, 17. Oktober 2025 23:22
An: tcl...@li...
Cc: 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

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

Re: [TCLCORE] CFV Warning - TIP 733

[Jan N. <jan...@gm...>]

Op za 18 okt 2025 om 23:07 schreef Kevin Walzer:
> 2. Jan noted that the test suite failed on all three platforms during
> automated Github runs. I added code to accessibility.tcl to return an
> empty namespace if a screen reader isn't running. That way there will be
> no unintended side effects from the accessibility commands conflicting
> with the test suite, which  now runs normally on all three platforms.
> Note: I am NOT including automated testing of accessibility within the
> test suite itself. Accessibility is best tested through interactive use
> of a screen reader.

Unfortunately, testcases are still failing when there is no
    screen-reader. e.g.:
    ==== font-1.1 TkFontPkgInit FAILED
    ==== Contents of test case:
    interp create foo
    foo eval {
    load {} Tk
    ....
    invalid command name "::tk::accessible::check_screenreader"
    while executing
    "::tk::accessible::check_screenreader"
    invoked from within
    "if {([::tk::accessible::check_screenreader] eq 0 ||
[::tk::accessible::check_screenreader] eq "")} {
    # Do not load if screen reader is not running..."
    (file "/Users/runner/work/tk/tk/tk/library/accessibility.tcl" line 14)
    invoked from within

<https://github.com/tcltk/tk/actions/runs/18675529789/job/5324461262>

This is on Linux. but Windows and MacOS fail too

:-(
    Jan Nijtmans

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

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

Thanks for the feedback, Brian! I understand your concern about the
semantic distinction between $ (value) and [ ] (execution).

I'd offer a few thoughts:

1. Shell precedent: The $(command) syntax is well-established in bash/sh
for command substitution. Tcl users familiar with shell scripting would
find this natural, not confusing.

2. $ already involves execution: Even $var involves command execution
internally (TclGetVar), it's just optimized. The distinction between "value
substitution" and "command execution" is somewhat artificial at the
implementation level.

3.  expr is special and has historical precedent: Unlike arbitrary
commands, expr is used so frequently that syntactic sugar makes sense -
similar to how $var is sugar for [set var]. We optimize the common case. I
believe there was a time in early Tcl before $var existed when [set var]
was the only choice - if so, adding $var as syntactic sugar for variable
substitution was a usability win. $(expr) follows the same pattern - sugar
for the extremely common [expr {...}] case.

4. Consistency: $(expr) fits the pattern of "$ means substitute something
here" - whether a variable, array element, or expression result. Modern
languages like Python have embraced similar concepts with f-strings that
allow {expression} for inline evaluation. $(expr) brings this convenience
to Tcl while maintaining our substitution semantics.

That said, I appreciate the philosophical consistency argument. Do you see
the security benefits (auto-bracing) as compelling enough to outweigh the
semantic concern?

Did you see the email I sent you about lseq? Maybe it landed in your spam
folder - that happened once before as I recall.

Eric


On Mon, Oct 20, 2025 at 7:19 PM Brian Griffin <bri...@ea...>
wrote:

> I like the idea of simplifying expression substitutions.  The problem I
> have is that the '$' is defined to be a value substitution. Running a
> command (execution) is a [] substitution, not a '$' substitution.
> Conflating the two modes of substitution can cause confusion for newbies,
> and even experienced programmers.
>
> I recognize that this view is a very subtle distinction, but I think it's
> important.
>
> Think of it like conflating * vs & in C.  (Maybe not that bad, but similar)
>
> -Brian
>
> On Oct 20, 2025, at 07:22, EricT <tw...@gm...> wrote:
>
> Regarding the discussion in the telco today. If the incompatibility
> discussed is the known empty array issue, then for that I would propose the
> following:
>
> There could be a pragma or tcl_dollar_expr global variable with several
> settings.
>
> 1. Work in compatibility mode, i.e. as though the feature was not
> implemented at all.
> 2. Work in diagnostic mode, throw an error for any $(...) use
> 3. Work in full implementation mode
>
> The code to do this, given a global C variable to check would be trivial.
>
> This value could default to 1. for at least 9.1 or 9.2 but there could be
> an option, similar to tclsh -encoding, that would allow the pragma variable
> to be set before any init script code is run. This would give developers
> the opportunity to set the variable to mode 2 in order to easily track down
> uses of $(index) before any code were to begin using $(expr).
>
> I think it would be quite rare if this syntax change would affect binary
> extensions, so it should be only with script level coding.
>
> The fix to any code that is using the empty array variable, is to change
> from,
>
>     set val $(index)
>     set val $($var)  - or any other valid index string
>
> to
>
>    set val ${(index)}
>    set val ${($var)}
>
> Likewise for any other use of the $(...) substitution in current use.
>
> This change can begin to be made right away, since it is a
> compatible syntax that does not change the semantics.  Once all the init
> time script code or packages that use the un-braced syntax are found and
> changed, the feature could begin to be used by those who are interested.
>
> On the other hand, if the incompatibility is something other than this
> empty array, I'd be most appreciative to know what it is.
>
> thanks
>
> Eric
>
>
> On Sun, Oct 19, 2025 at 3:44 AM EricT <tw...@gm...> wrote:
>
>> Harald,
>>
>> Thank you for your willingness to sponsor!
>>
>> To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl
>> user who, in retirement, wanted to give something back to the Tcl
>> community. Jim Tcl's successful use of this syntax for years demonstrates
>> that the concept is viable.
>>
>> Regarding the telco: I attempted to join previously but was unsuccessful
>> with the setup. I won't be able to participate on Monday, but I'm available
>> via email for any questions or clarifications that arise from the
>> discussion.
>>
>> I don't currently have write access to either the Tcl Fossil repository
>> or the TIP repository, so I'm unable to make changes directly. At nearly 80
>> years old, I'm not comfortable learning new version control systems on my
>> own. If the TIP moves forward, I'd need guidance and assistance with the
>> Fossil workflow, or perhaps someone from the core team who shares our
>> interest in this TIP could handle the integration based on my GitHub
>> prototype.
>>
>> I'm currently developing a comprehensive test suite in standard tcltest
>> format, with particular focus on edge cases.
>>
>> Looking forward to hearing how Monday's discussion goes!
>>
>> Best regards,
>> Eric
>>
>>
>> On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <
>> har...@el...> wrote:
>>
>>> Eric,
>>> sponsoring is no problem. The point is to get positive votes.
>>> This requires a positive discussion.
>>> You are the Author of Jim?
>>> Could you participate on the telco on Monday?
>>>
>>> Do you have write access to the tcl fossil? We would need the
>>> implementation there.
>>>
>>> Thanks for all,
>>> Harald
>>>
>>> Am 18.10.2025 um 22:58 schrieb EricT:
>>> > Thank you for the positive feedback and for raising this in Monday's
>>> > telco! I'm encouraged by your support.
>>> >
>>> > Regarding $(a) - you're right that reading an empty array element with
>>> a
>>> > variable index is a valid construct. However, this is explicitly
>>> > addressed in the TIP and the repository README. The workarounds are
>>> > straightforward:
>>> >
>>> >    ${(a)}        # Braced form
>>> >    [set (a)]     # Command substitution
>>> >
>>> > Both still work. In fact, code using $(varname) could be proactively
>>> > modified to use ${(varname)} to indicate the clear intent of an empty
>>> > array reference, which improves readability. The security,
>>> performance,
>>> > and usability benefits of $(...) seemed to justify this trade-off for
>>> > Tcl 9.x where some incompatibilities are expected.
>>> >
>>> > Given your interest in the feature, would you be willing to consider
>>> > sponsoring TIP 672? The implementation is working and minimal (~100
>>> > lines across two files), with the main open question being the
>>> preferred
>>> > approach for tracking synthetic strings for cleanup. Your guidance on
>>> > that architectural decision would be particularly valuable.
>>> >
>>> > The prototype repository with full implementation and examples is here:
>>> >
>>> > https://github.com/rocketship88/tcl-tip-672-prototype <https://
>>> > github.com/rocketship88/tcl-tip-672-prototype>
>>> >
>>> > Looking forward to the results of the discussion on Monday! I won't be
>>> > able to join the telco discussion, but I'm available via email for any
>>> > questions or clarifications that arise.
>>> >
>>> >
>>> > On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann
>>> > <har...@el... <mailto:har...@el...>>
>>> wrote:
>>> >
>>> >     Am 17.10.2025 um 23:22 schrieb EricT:
>>> >      > 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://github.com/rocketship88/tcl-tip-672-prototype>
>>> >      > <https://github.com/rocketship88/tcl-tip-672-prototype
>>> <https://
>>> >     github.com/rocketship88/tcl-tip-672-prototype>>
>>> >      >
>>> >      > 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
>>> >     Eric,
>>> >     great proposal, thank you !
>>> >
>>> >     Perhaps, we may discuss this on Monday in the biweekly telco.
>>> >     I am also excited and in favor to this.
>>> >     Nevertheless, "$(a)" is to my knowledge a quite common syntax for
>>> >     arrays. We have already killed less disruptive proposals (see
>>> optional
>>> >     "- args") by endless discussions and getting nowhere.
>>> >     Hope, this will be fruitful.
>>> >
>>> >     In addition, I would like to add the Tk test reform by the other
>>> >     Eric to
>>> >     the biweekly topics.
>>> >     Here is a revised agenda proposal proposal:
>>> >
>>> >     Top 1) Release calender (TIP 713)
>>> >     - 9.0.3: October (2 weeks left)
>>> >     - 9.1a1: November (6 weeks left)
>>> >     Top 2) TIP 734 nested mutex (go or not)
>>> >     Top 3) TIP 733: accessability (test status)
>>> >     Top 4) TIP 732: TCL library path (discussion)
>>> >     Top 5) TIP 731: use C enums (no brainer?)
>>> >     Top 6) TIP 720: new bytecodes (final, great! Any issues?)
>>> >     Top 7) TIP 721: Tcl_AttemptGetString
>>> >     Top 8) TIP 715: supported build systems
>>> >     Top 9) $($a+$b) syntax for expressions
>>> >     Top 10) Tk test reform by Eric (Thanks !)
>>> >     Top 11) Tcl depot and awthemes ?
>>> >     Top 12) AOB
>>> >     Top 13) Next meeting:
>>> >           3rd of November 12:00 UTC.
>>> >           Daytime saving time ends 2nd of November in US, 26th of
>>> >     October in
>>> >     Europe.
>>> >           Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?
>>> >
>>> >     Take care,
>>> >     Harald
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>
>> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

Kevin:

If {=} parallels {*} as you mention, does that mean it would only work as a
separate word, and not inside quoted or unquoted strings? And what about
mixing command substitutions with numerical operations.

func {=}{[string length $str] + 1}
puts "result: {=}{$x + 1}"
set x prefix{=}{$x + 1}suffix
lrange $list 0 end-{=}{$x + 2}

This is important since $(expr) works in all these contexts because $
already triggers substitution there.

Eric


On Mon, Oct 20, 2025 at 7:31 PM Kevin Kenny <kev...@gm...> wrote:

> On Mon, Oct 20, 2025 at 7:22 PM EricT <tw...@gm...> wrote:
>
>> You're right that {=}{expression} avoids this particular incompatibility. I think {=} could potentially work, though my sense is it would require more extensive parser changes to handle quotes and bare words (where $ already works naturally). But I could be wrong about the implementation complexity.
>>
>>
> The parser changes are pretty minimal, and nearly parallel to the
> implementation of {*}. The {=} would be presumed to be followed by a
> 'word', with all the usual rules that implies.
>
> {=}{$a + $b} would be parsed by the ordinary balancing of curly braces,
> followed by processing the content as an expression.
>
> {=}[command], {=}"quoted string", {=}$var, etc, would all have natural
> meanings equivalent to applying [expr] to the substituted value.
> (Ordinarily, those uses should be advised against, since all these forms
> ask for double substitution and invite code injection attacks, but I can
> see them having their place in some specialized contexts, and the syntax is
> thereby rendered uniform.)
>
> (I'd actually favor {$} over {=}, and instead reserve {=} for the
> possibility of a new 'little language' for less cumbersome expressions (in
> particular, automatic $-substitution of barewords, and implementation of =
> for assignment. But that's a different idea altogether, and has had several
> rejected or abandoned TIPs over the years.)
>
> --
> 73 de ke9tv/2, Kevin
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

[Kevin K. <kev...@gm...>]

On Mon, Oct 20, 2025 at 7:22 PM EricT <tw...@gm...> wrote:

> You're right that {=}{expression} avoids this particular incompatibility. I think {=} could potentially work, though my sense is it would require more extensive parser changes to handle quotes and bare words (where $ already works naturally). But I could be wrong about the implementation complexity.
>
>
The parser changes are pretty minimal, and nearly parallel to the
implementation of {*}. The {=} would be presumed to be followed by a
'word', with all the usual rules that implies.

{=}{$a + $b} would be parsed by the ordinary balancing of curly braces,
followed by processing the content as an expression.

{=}[command], {=}"quoted string", {=}$var, etc, would all have natural
meanings equivalent to applying [expr] to the substituted value.
(Ordinarily, those uses should be advised against, since all these forms
ask for double substitution and invite code injection attacks, but I can
see them having their place in some specialized contexts, and the syntax is
thereby rendered uniform.)

(I'd actually favor {$} over {=}, and instead reserve {=} for the
possibility of a new 'little language' for less cumbersome expressions (in
particular, automatic $-substitution of barewords, and implementation of =
for assignment. But that's a different idea altogether, and has had several
rejected or abandoned TIPs over the years.)

-- 
73 de ke9tv/2, Kevin

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

[Brian G. <bri...@ea...>]

I like the idea of simplifying expression substitutions.  The problem I have is that the '$' is defined to be a value substitution. Running a command (execution) is a [] substitution, not a '$' substitution.  Conflating the two modes of substitution can cause confusion for newbies, and even experienced programmers.

I recognize that this view is a very subtle distinction, but I think it's important.

Think of it like conflating * vs & in C.  (Maybe not that bad, but similar)

-Brian

On Oct 20, 2025, at 07:22, EricT <tw...@gm...> wrote:

Regarding the discussion in the telco today. If the incompatibility discussed is the known empty array issue, then for that I would propose the following:

There could be a pragma or tcl_dollar_expr global variable with several settings.

1. Work in compatibility mode, i.e. as though the feature was not implemented at all.
2. Work in diagnostic mode, throw an error for any $(...) use
3. Work in full implementation mode

The code to do this, given a global C variable to check would be trivial.

This value could default to 1. for at least 9.1 or 9.2 but there could be an option, similar to tclsh -encoding, that would allow the pragma variable to be set before any init script code is run. This would give developers the opportunity to set the variable to mode 2 in order to easily track down uses of $(index) before any code were to begin using $(expr).

I think it would be quite rare if this syntax change would affect binary extensions, so it should be only with script level coding.

The fix to any code that is using the empty array variable, is to change from,

    set val $(index)
    set val $($var)  - or any other valid index string

to

   set val ${(index)}
   set val ${($var)}

Likewise for any other use of the $(...) substitution in current use.

This change can begin to be made right away, since it is a compatible syntax that does not change the semantics.  Once all the init time script code or packages that use the un-braced syntax are found and changed, the feature could begin to be used by those who are interested.

On the other hand, if the incompatibility is something other than this empty array, I'd be most appreciative to know what it is.

thanks

Eric


On Sun, Oct 19, 2025 at 3:44 AM EricT <tw...@gm...<mailto:tw...@gm...>> wrote:
Harald,

Thank you for your willingness to sponsor!

To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl user who, in retirement, wanted to give something back to the Tcl community. Jim Tcl's successful use of this syntax for years demonstrates that the concept is viable.

Regarding the telco: I attempted to join previously but was unsuccessful with the setup. I won't be able to participate on Monday, but I'm available via email for any questions or clarifications that arise from the discussion.

I don't currently have write access to either the Tcl Fossil repository or the TIP repository, so I'm unable to make changes directly. At nearly 80 years old, I'm not comfortable learning new version control systems on my own. If the TIP moves forward, I'd need guidance and assistance with the Fossil workflow, or perhaps someone from the core team who shares our interest in this TIP could handle the integration based on my GitHub prototype.

I'm currently developing a comprehensive test suite in standard tcltest format, with particular focus on edge cases.

Looking forward to hearing how Monday's discussion goes!

Best regards,
Eric


On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <har...@el...<mailto:har...@el...>> wrote:
Eric,
sponsoring is no problem. The point is to get positive votes.
This requires a positive discussion.
You are the Author of Jim?
Could you participate on the telco on Monday?

Do you have write access to the tcl fossil? We would need the
implementation there.

Thanks for all,
Harald

Am 18.10.2025 um 22:58 schrieb EricT:
> Thank you for the positive feedback and for raising this in Monday's
> telco! I'm encouraged by your support.
>
> Regarding $(a) - you're right that reading an empty array element with a
> variable index is a valid construct. However, this is explicitly
> addressed in the TIP and the repository README. The workarounds are
> straightforward:
>
>    ${(a)}        # Braced form
>    [set (a)]     # Command substitution
>
> Both still work. In fact, code using $(varname) could be proactively
> modified to use ${(varname)} to indicate the clear intent of an empty
> array reference, which improves readability. The security, performance,
> and usability benefits of $(...) seemed to justify this trade-off for
> Tcl 9.x where some incompatibilities are expected.
>
> Given your interest in the feature, would you be willing to consider
> sponsoring TIP 672? The implementation is working and minimal (~100
> lines across two files), with the main open question being the preferred
> approach for tracking synthetic strings for cleanup. Your guidance on
> that architectural decision would be particularly valuable.
>
> The prototype repository with full implementation and examples is here:
>
> https://github.com/rocketship88/tcl-tip-672-prototype <https://
> github.com/rocketship88/tcl-tip-672-prototype<http://github.com/rocketship88/tcl-tip-672-prototype>>
>
> Looking forward to the results of the discussion on Monday! I won't be
> able to join the telco discussion, but I'm available via email for any
> questions or clarifications that arise.
>
>
> On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann
> <har...@el...<mailto:har...@el...> <mailto:har...@el...<mailto:har...@el...>>> wrote:
>
>     Am 17.10.2025 um 23:22 schrieb EricT:
>      > 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://github.com/rocketship88/tcl-tip-672-prototype>
>      > <https://github.com/rocketship88/tcl-tip-672-prototype <https://
>     github.com/rocketship88/tcl-tip-672-prototype<http://github.com/rocketship88/tcl-tip-672-prototype>>>
>      >
>      > 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
>     Eric,
>     great proposal, thank you !
>
>     Perhaps, we may discuss this on Monday in the biweekly telco.
>     I am also excited and in favor to this.
>     Nevertheless, "$(a)" is to my knowledge a quite common syntax for
>     arrays. We have already killed less disruptive proposals (see optional
>     "- args") by endless discussions and getting nowhere.
>     Hope, this will be fruitful.
>
>     In addition, I would like to add the Tk test reform by the other
>     Eric to
>     the biweekly topics.
>     Here is a revised agenda proposal proposal:
>
>     Top 1) Release calender (TIP 713)
>     - 9.0.3: October (2 weeks left)
>     - 9.1a1: November (6 weeks left)
>     Top 2) TIP 734 nested mutex (go or not)
>     Top 3) TIP 733: accessability (test status)
>     Top 4) TIP 732: TCL library path (discussion)
>     Top 5) TIP 731: use C enums (no brainer?)
>     Top 6) TIP 720: new bytecodes (final, great! Any issues?)
>     Top 7) TIP 721: Tcl_AttemptGetString
>     Top 8) TIP 715: supported build systems
>     Top 9) $($a+$b) syntax for expressions
>     Top 10) Tk test reform by Eric (Thanks !)
>     Top 11) Tcl depot and awthemes ?
>     Top 12) AOB
>     Top 13) Next meeting:
>           3rd of November 12:00 UTC.
>           Daytime saving time ends 2nd of November in US, 26th of
>     October in
>     Europe.
>           Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?
>
>     Take care,
>     Harald
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core
_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

When you created your array, the index was (2+2) which is 5 chars in
length, and you set the value to 5. When you wanted to retrieve it as an
array(index) and array was actually the null variable, you needed to do
((2+2)) in order to enclose your index in parentheses. You could probably
see it more clearly as,

% set foo((2+2)) 5
5
% array name foo
(2+2)
% puts $foo((2+2))
can't read "foo((2+2)": no such element in array
% set foo((2+2))
5

However, that is 8.6, and the problem appears to be that they stopped at
the first close paren, without doing any balancing. With 9.1 I see the new
error, same as you are getting, although to try it out I had to use a real
array name. Looking at the code, there's a change in 9.x which includes
this and explains the different error messages:

} else if ((*parsePtr->term != ')')){
 if (parsePtr->interp != NULL) {
   Tcl_SetObjResult(parsePtr->interp, Tcl_NewStringObj(
   "invalid character in array index", -1));
 }


The else if is checking the terminating character for the parse. Stepping
it through however, I see that it actually is pointing to the 2nd open
paren following the array name. So, it has scanned the name, saw the first
(, changed to the array logic, but seems to not be pointing at the final
close ) as I would have expected it to and what this code seems to think it
should be as well. This may be a bug. It could explain why they added this
change, but it fails when the first character in the index is an open
paren. You might want to file a ticket on this.

Eric


On Mon, Oct 20, 2025 at 5:34 PM Phillip Brooks <phi...@um...> wrote:

> Thanks for the explanation.   Yes, I did try to run both commands
> together.  I see what is going on with that statement now.  I was unaware
> of the possibility of having an unnamed array previously.
>
> Regarding my Tcl version, I am running vanilla 9.1 of a fairly recent
> vintage, but also tried using 8.5.
>
> Regarding the double parenthesis expression proposal, I'm not sure that I
> follow you.  Is there a way to use the single argument set command to
> create an ambiguity between $(( expression )) as an arithmetic expression
> evaluator and some existing code using an unnamed array, or set (or any
> other currently legal syntax)?  Since that command doesn't involve the $
> character, I don't see how it gets in the way.  If you can think of one,
> can you write a couple of lines of code that illustrate it?
>
> Phil
>
>
>
> On Mon, Oct 20, 2025 at 5:07 PM EricT <tw...@gm...> wrote:
>
>> I believe the reason you got the error was that you actually typed both
>> statements, setting the scalar null variable and then tried the array null
>> variable.
>>
>> However, I believe the problem is that you are running into some parser
>> issues here that the manual doesn't mention. It does, however, say
>>
>> Note that variables may contain character sequences other than those
>> listed above, but in that case other mechanisms must be used to access them
>> (e.g., via the *set *command's single-argument form).
>>
>> And so that is why the above using set does return the value 5. But when
>> trying $ substitution, the rules are more restrictive, and you likely hit
>> one of the edge cases here.
>>
>> Eric
>>
>>
>> On Mon, Oct 20, 2025 at 4:30 PM Phillip Brooks <phi...@um...>
>> wrote:
>>
>>> Let me try making my previous email a little more concise since it
>>> hasn't generated any follow-ups.
>>>
>>> 1) Is there a bust in the TIP 672 example code.  I can't run this code
>>> from the TIP:
>>>
>>> set {} foobar             ;# scalar variable
>>>
>>> set (index) "array value" ;# array variable
>>>
>>> When I run that, I get:
>>>
>>> can't set "(index)": variable isn't array
>>>
>>>
>>> Please explain.
>>>
>>> 2) The bash shell uses the syntax $(( expression )) for arithmetic.
>>> Does that syntax solve the problem of the unnamed array ambiguity that $(
>>> expression ) introduces?  The $(( expression )) syntax, at least in my
>>> small example, seems illegal.  I am only testing this out on a simple case
>>> I tried after the above code didn't work:
>>>
>>> % array set {} { 2+2 5 }
>>>
>>> % puts $(2+2)
>>>
>>> 5
>>>
>>>
>>> The above code illustrates the problem with $(2+2) being interpreted as
>>> an index into the unnamed array.  If I try doing that with an extra ( in
>>> the expression, it is invalid syntax:
>>>
>>> % array set {} { (2+2) 5 }
>>>
>>> % puts $((2+2))
>>>
>>> invalid character in array index
>>>
>>>
>>> To get at the array element named (2+2), you have to add escape
>>> characters:
>>>
>>>
>>> % puts $(\(2+2\))
>>>
>>> 5
>>>
>>>
>>> It seems to me that if $(( expression )) works generally, it has several
>>> advantages:
>>>
>>>    - it is easier to read and type than {=}{ expression }.  (While {=}
>>>    adds only two characters, { and } are shifted, = is unshifted which makes
>>>    for much slower typing.)
>>>    - it has precedent in bash
>>>    - it doesn't overload the meaning of preexisting valid syntax.
>>>
>>> Are there other issues with $(( expression )) that I don't know of?
>>> Please explain?
>>>
>>> Phil
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>
>> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

[Phillip B. <phi...@um...>]

Thanks for the explanation.   Yes, I did try to run both commands
together.  I see what is going on with that statement now.  I was unaware
of the possibility of having an unnamed array previously.

Regarding my Tcl version, I am running vanilla 9.1 of a fairly recent
vintage, but also tried using 8.5.

Regarding the double parenthesis expression proposal, I'm not sure that I
follow you.  Is there a way to use the single argument set command to
create an ambiguity between $(( expression )) as an arithmetic expression
evaluator and some existing code using an unnamed array, or set (or any
other currently legal syntax)?  Since that command doesn't involve the $
character, I don't see how it gets in the way.  If you can think of one,
can you write a couple of lines of code that illustrate it?

Phil



On Mon, Oct 20, 2025 at 5:07 PM EricT <tw...@gm...> wrote:

> I believe the reason you got the error was that you actually typed both
> statements, setting the scalar null variable and then tried the array null
> variable.
>
> However, I believe the problem is that you are running into some parser
> issues here that the manual doesn't mention. It does, however, say
>
> Note that variables may contain character sequences other than those
> listed above, but in that case other mechanisms must be used to access them
> (e.g., via the *set *command's single-argument form).
>
> And so that is why the above using set does return the value 5. But when
> trying $ substitution, the rules are more restrictive, and you likely hit
> one of the edge cases here.
>
> Eric
>
>
> On Mon, Oct 20, 2025 at 4:30 PM Phillip Brooks <phi...@um...> wrote:
>
>> Let me try making my previous email a little more concise since it hasn't
>> generated any follow-ups.
>>
>> 1) Is there a bust in the TIP 672 example code.  I can't run this code
>> from the TIP:
>>
>> set {} foobar             ;# scalar variable
>>
>> set (index) "array value" ;# array variable
>>
>> When I run that, I get:
>>
>> can't set "(index)": variable isn't array
>>
>>
>> Please explain.
>>
>> 2) The bash shell uses the syntax $(( expression )) for arithmetic.  Does
>> that syntax solve the problem of the unnamed array ambiguity that $(
>> expression ) introduces?  The $(( expression )) syntax, at least in my
>> small example, seems illegal.  I am only testing this out on a simple case
>> I tried after the above code didn't work:
>>
>> % array set {} { 2+2 5 }
>>
>> % puts $(2+2)
>>
>> 5
>>
>>
>> The above code illustrates the problem with $(2+2) being interpreted as
>> an index into the unnamed array.  If I try doing that with an extra ( in
>> the expression, it is invalid syntax:
>>
>> % array set {} { (2+2) 5 }
>>
>> % puts $((2+2))
>>
>> invalid character in array index
>>
>>
>> To get at the array element named (2+2), you have to add escape
>> characters:
>>
>>
>> % puts $(\(2+2\))
>>
>> 5
>>
>>
>> It seems to me that if $(( expression )) works generally, it has several
>> advantages:
>>
>>    - it is easier to read and type than {=}{ expression }.  (While {=}
>>    adds only two characters, { and } are shifted, = is unshifted which makes
>>    for much slower typing.)
>>    - it has precedent in bash
>>    - it doesn't overload the meaning of preexisting valid syntax.
>>
>> Are there other issues with $(( expression )) that I don't know of?
>> Please explain?
>>
>> Phil
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>