Menu
▾
▴
Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
|
From: Florent M. <flo...@gm...> - 2025-10-21 18:23:45
|
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 list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
--
------------------------------------------------------------------------
*Florent MERLET*
/4 rue Johann Strauss
Logement 7
86180 BUXEROLLES/
------------------------------------------------------------------------
*Mél.* : /flo...@gm.../
*Tél.* : /06 70 00 63 48/
|
