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