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
>