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