Menu
▾
▴
Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
|
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/
|
