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
>