Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[EricT <tw...@gm...>]

I don't think you are correct about {*} in a bareword that's not in quotes:

% proc foo args {puts /$args/}
% foo something{*}{1 + 2 + 3}suffix
/something\{*\}\{1 + 2 + 3\}suffix/
% foo something{*}{1+2+3}suffix
/something{*}{1+2+3}suffix/
% foo {*}{1 2 3}
/1 2 3/
% foo {*}"1 2 3"
/1 2 3/
% foo {*}"123"
/123/
In either of the first 2 cases, it is inserting the {*}{...} as simply
text, it is not removing the {*} nor the enclosing {...} and then expanding
it to a list. However, it does do all those steps in the 3rd - 5th cases
because {*} begins the word.

Eric


On Tue, Oct 21, 2025 at 11:37 AM EricT <tw...@gm...> wrote:

> 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
>>
>