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
>