Menu
▾
▴
tcl-core
|
From: Florent M. <flo...@gm...> - 2025-10-21 20:22:22
|
It's true
in tcl ParseVarName :
3. The $ sign is followed by something that isn't a letter, digit, or
* underscore: in this case, there is no variable name and the
token is
* just "$".
There is many possibilities finaly
for instance
% set x $/1+2
% set x $!1+2
are possible as well
Florent
Le 21/10/2025 à 21:24, Donald Porter a écrit :
> The {*} syntax introduced in Tcl 8.5 was a syntax for revising the determination of word boundaries. It needed to be connected to words.
>
> That is not what the current discussion seeks.
> The current discussion seeks to introduce syntax for a new form of substitution.
>
> The particular proposal for syntax $(…) suffers from the problem that it is already a working substitution syntax for the substitution of an element in an array variable with the empty name.
>
> Without thinking deeply and exhaustively about it, let me toss out the option of
>
> $=(…)
>
> This syntax does not currently perform a substitution. It is just literal text. Promoting it to a substitution syntax should be less disruptive.
>
> DGP
>
>
>
--
------------------------------------------------------------------------
*Florent MERLET*
/4 rue Johann Strauss
Logement 7
86180 BUXEROLLES/
------------------------------------------------------------------------
*Mél.* : /flo...@gm.../
*Tél.* : /06 70 00 63 48/
|
|
From: Florent M. <flo...@gm...> - 2025-10-21 19:57:53
|
if {=} is a valid string, does it mean it has ever been used in the code
base ?
in tcl repro :
https://github.com/search?q=repo%3Atcltk%2Ftcl%20%7B%3D%7D&type=code
one occurence in tools/regexpTestLib.tcl
<https://github.com/tcltk/tcl/blob/a9f6ab7dba8851da58fec404aa3fa4679bac0e93/tools/regexpTestLib.tcl#L198>
=> if {[regexp {=} $flags] == 1} # (false positive)
in tk repro :
https://github.com/search?q=repo%3Atcltk%2Ftk%20%7B%3D%7D&type=code
no occurence
in tcllib repro :
https://github.com/search?q=repo%3Atcltk%2Ftcllib%20{%3D}&type=code
no occurence
in tklib repro :
https://github.com/search?q=repo%3Atcltk%2Ftklib%20{%3D}&type=code
no occurence.
I don't see any breakage there.
Le 21/10/2025 à 21:11, da Silva, Peter J a écrit :
>
> If “{=}” is detected inside tokens this will cause all kinds of
> breakage that is going to be a lot harder to keep track of than
> “$(...)”, because right now “{=}” is a valid string in Tcl.
>
> The {*} special case at the beginning of an argument was safe because
> no valid Tcl code could have {*}... as an element of a list.
>
> *From: *Florent Merlet <flo...@gm...>
> *Date: *Tuesday, October 21, 2025 at 14:05
> *To: *tc...@ro... <tc...@ro...>
> *Cc: *tcl...@li... <tcl...@li...>
> *Subject: *Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 -
> $(expr) Syntax
>
> Yes you are right, I was wrong, {*} is not implemented into
> Tcl_ParseToken. There is no need for it. But it can't be the same for
> an {=} prefix : it should be detected inside tokens. Florent Le
> 21/10/2025 à 20: 54, EricT a écrit : I don't think
>
> Yes you are right, I was wrong, {*} is not implemented into
> Tcl_ParseToken.
>
> There is no need for it.
>
> But it can't be the same for an {=} prefix : it should be detected
> inside tokens.
>
> Florent
>
> Le 21/10/2025 à 20:54, EricT a écrit :
>
> 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
> <https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=kOgnKtNg5S0p_z-nZS7HAnBrb0GrBKOlYvbsUmtlt7w&e=>
>
> 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
> <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
>
>
>
>
> _______________________________________________
>
> Tcl-Core mailing list
>
> Tcl...@li...
>
> https://lists.sourceforge.net/lists/listinfo/tcl-core <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
>
> --
>
> ------------------------------------------------------------------------
>
> *Florent MERLET*
> /4 rue Johann Strauss
> Logement 7
> 86180 BUXEROLLES/
>
> ------------------------------------------------------------------------
>
> *Mél.* : /flo...@gm.../
> *Tél.* : /06 70 00 63 48/
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
>
> --
>
> ------------------------------------------------------------------------
>
> *Florent MERLET*
> /4 rue Johann Strauss
> Logement 7
> 86180 BUXEROLLES/
>
> ------------------------------------------------------------------------
>
> *Mél.* : /flo...@gm.../
> *Tél.* : /06 70 00 63 48/
>
--
------------------------------------------------------------------------
*Florent MERLET*
/4 rue Johann Strauss
Logement 7
86180 BUXEROLLES/
------------------------------------------------------------------------
*Mél.* : /flo...@gm.../
*Tél.* : /06 70 00 63 48/
|
|
From: da S. P. J <pet...@fl...> - 2025-10-21 20:15:33
|
> if {=} is a valid string, does it mean it has ever been used in the code base ?
Wrong question.
The question is, is any string containing “{=}” going to be passed to subst in anyone’s code anywhere in the world. It was safe to use “{*}” at the beginning of a token because that was not legal Tcl. No working code could contain that string, and it was only exposed in the context of actual auditable code.
From: Florent Merlet <flo...@gm...>
Date: Tuesday, October 21, 2025 at 14:57
To: da Silva, Peter J (USA) <pet...@fl...>, tc...@ro... <tc...@ro...>
Cc: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
if {=} is a valid string, does it mean it has ever been used in the code base ? in tcl repro : https: //github. com/search?q=repo%3Atcltk%2Ftcl%20%7B%3D%7D&type=code one occurence in tools/regexpTestLib. tcl => if {[regexp {=} $flags] ==
if {=} is a valid string, does it mean it has ever been used in the code base ?
in tcl repro : https://github.com/search?q=repo%3Atcltk%2Ftcl%20%7B%3D%7D&type=code<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftcl-2520-257B-253D-257D-26type-3Dcode&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=CyfsegsVMbQTM8BUOM3QAFgUyMu6A2qql4-wcgXkTWU&e=>
one occurence in tools/regexpTestLib.tcl<https://urldefense.us/v2/url?u=https-3A__github.com_tcltk_tcl_blob_a9f6ab7dba8851da58fec404aa3fa4679bac0e93_tools_regexpTestLib.tcl-23L198&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=f_l9v0uAjxDkCoCD983cJCGF1mO5AEgDEvVHYj8xrU0&e=>
=> if {[regexp {=} $flags] == 1} # (false positive)
in tk repro : https://github.com/search?q=repo%3Atcltk%2Ftk%20%7B%3D%7D&type=code<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftk-2520-257B-253D-257D-26type-3Dcode&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=9Me6yTEagX62EN9QV2Qqu-oAyS4V4bOeKRMORRz5fqg&e=>
no occurence
in tcllib repro : https://github.com/search?q=repo%3Atcltk%2Ftcllib%20<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftcllib-2520&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=24_EwvyMubvwYtieY_qXCr60SaMCmKc0ZzDnc3oFAG0&e=>{%3D}&type=code
no occurence
in tklib repro : https://github.com/search?q=repo%3Atcltk%2Ftklib%20<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftklib-2520&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=NfS1Gl9HPof5QLWw5x6P7PK7dpYz48q3bPWrzfg2XuY&e=>{%3D}&type=code
no occurence.
I don't see any breakage there.
Le 21/10/2025 à 21:11, da Silva, Peter J a écrit :
If “{=}” is detected inside tokens this will cause all kinds of breakage that is going to be a lot harder to keep track of than “$(...)”, because right now “{=}” is a valid string in Tcl.
The {*} special case at the beginning of an argument was safe because no valid Tcl code could have {*}... as an element of a list.
From: Florent Merlet <flo...@gm...><mailto:flo...@gm...>
Date: Tuesday, October 21, 2025 at 14:05
To: tc...@ro...<mailto:tc...@ro...> <tc...@ro...><mailto:tc...@ro...>
Cc: tcl...@li...<mailto:tcl...@li...> <tcl...@li...><mailto:tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
Yes you are right, I was wrong, {*} is not implemented into Tcl_ParseToken. There is no need for it. But it can't be the same for an {=} prefix : it should be detected inside tokens. Florent Le 21/10/2025 à 20: 54, EricT a écrit : I don't think
Yes you are right, I was wrong, {*} is not implemented into Tcl_ParseToken.
There is no need for it.
But it can't be the same for an {=} prefix : it should be detected inside tokens.
Florent
Le 21/10/2025 à 20:54, EricT a écrit :
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...<mailto: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...<mailto: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...<mailto: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...<mailto:tw...@gm...>>
Gesendet: Dienstag, 21. Oktober 2025 14:53
An: Zaumseil René <RZa...@kk...<mailto:RZa...@kk...>>
Cc: tc...@ro...<mailto:tc...@ro...>; tcl...@li...<mailto:tcl...@li...>; et...@ro...<mailto: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<https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=kOgnKtNg5S0p_z-nZS7HAnBrb0GrBKOlYvbsUmtlt7w&e=>
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<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
--
________________________________
Florent MERLET
4 rue Johann Strauss
Logement 7
86180 BUXEROLLES
________________________________
Mél. : flo...@gm...<mailto:flo...@gm...>
Tél. : 06 70 00 63 48
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
--
________________________________
Florent MERLET
4 rue Johann Strauss
Logement 7
86180 BUXEROLLES
________________________________
Mél. : flo...@gm...<mailto:flo...@gm...>
Tél. : 06 70 00 63 48
--
________________________________
Florent MERLET
4 rue Johann Strauss
Logement 7
86180 BUXEROLLES
________________________________
Mél. : flo...@gm...<mailto:flo...@gm...>
Tél. : 06 70 00 63 48
|
|
From: Colin M. <col...@ya...> - 2025-10-25 16:17:19
|
(Sorry, I just can't stay away from the bikeshed) :-)
Kevin mentions the idea of having expression evaluation interpret bare
words as variable references without requiring $ in front.
On 21/10/2025 03:30, Kevin Kenny wrote:
> (I'd actually favor {$} over {=}, and instead reserve {=} for the
> possibility of a new 'little language' for less cumbersome expressions
> (in particular, automatic $-substitution of barewords, and
> implementation of = for assignment.
It occurs to me now that an expr alternative which does this can avoid
the whole double substitution issue. If you can write x*2-3 instead of
$x*2-3 there's no need to brace the expression because x cannot be
prematurely substituted before the expression code sees it.
If `=` was defined to concatenate its arguments and then treat the
result as an expression where barewords are interpreted as variable
references, you could write [= x*2-3] to do this calculation in a form
which is both safe, compact, and fully conforms to the existing
dodekalogue rules.
As with my proposal in tip 676, this probably needs to be restricted to
numeric and boolean operations, string literals would be difficult to
accommodate.
Of course it would still be possible to write $ substitutions within the
expression, but this would not normally be needed and the documentation
should warn that this is risky.
Substitutions of [command] would work as long as command returns a
single numeric or boolean value. However if that value gets concatenated
into a string its numeric representation will be shimmered away. It may
be possible to avoid this if [command] is given as a separate argument,
i.e. [= 2* [llength $list] -1] not [= 2*[llength $list]-1], by checking
for a numeric representation before concatenating arguments.
However the main usefulness of this facility would be for short, simple
expressions like [= x*2-3] (9 chars) where the verbosity of [expr
{$x*2-3}] (15 chars) is cumbersome. The proposed $(($x*2-3)) is longer
(11 chars) *and* requires an update to the dodekalogue, something not to
be undertaken lightly.
Colin.
|
|
From: Colin M. <col...@ya...> - 2025-10-26 09:30:13
|
On the chat Schelte pointed out that this approach would have difficulty
distinguishing array references from mathfunc calls - e.g. does
`min(2,3)` mean 2 or the value at index "2,3" in array min.
I think resolving this without nasty surprises would require disallowing
bareword array references, so `min(2,3)` would always call function
min(). I you really need a value from an array you can use e.g.
`$min(2,3)` to have it pre-substituted, with the caveat that odd things
may happen if that value is not a single number.
Colin.
On 25/10/2025 17:17, Colin Macleod via Tcl-Core wrote:
>
> (Sorry, I just can't stay away from the bikeshed) :-)
>
> Kevin mentions the idea of having expression evaluation interpret bare
> words as variable references without requiring $ in front.
>
> On 21/10/2025 03:30, Kevin Kenny wrote:
>
>> (I'd actually favor {$} over {=}, and instead reserve {=} for the
>> possibility of a new 'little language' for less cumbersome
>> expressions (in particular, automatic $-substitution of barewords,
>> and implementation of = for assignment.
> It occurs to me now that an expr alternative which does this can avoid
> the whole double substitution issue. If you can write x*2-3 instead
> of $x*2-3 there's no need to brace the expression because x cannot be
> prematurely substituted before the expression code sees it.
>
> If `=` was defined to concatenate its arguments and then treat the
> result as an expression where barewords are interpreted as variable
> references, you could write [= x*2-3] to do this calculation in a form
> which is both safe, compact, and fully conforms to the existing
> dodekalogue rules.
>
> As with my proposal in tip 676, this probably needs to be restricted
> to numeric and boolean operations, string literals would be difficult
> to accommodate.
>
> Of course it would still be possible to write $ substitutions within
> the expression, but this would not normally be needed and the
> documentation should warn that this is risky.
>
> Substitutions of [command] would work as long as command returns a
> single numeric or boolean value. However if that value gets
> concatenated into a string its numeric representation will be
> shimmered away. It may be possible to avoid this if [command] is given
> as a separate argument, i.e. [= 2* [llength $list] -1] not [=
> 2*[llength $list]-1], by checking for a numeric representation before
> concatenating arguments.
>
> However the main usefulness of this facility would be for short,
> simple expressions like [= x*2-3] (9 chars) where the verbosity of
> [expr {$x*2-3}] (15 chars) is cumbersome. The proposed $(($x*2-3)) is
> longer (11 chars) *and* requires an update to the dodekalogue,
> something not to be undertaken lightly.
>
> Colin.
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core |
Thanks for helping keep SourceForge clean.
X