|
From: da S. P. J <pet...@fl...> - 2025-10-20 15:11:20
|
Obviously I think this is a great idea and I think anyone who actually uses $(thing) in production code is crazy, but when I brought it up it got shot down because it was apparently found in the wild in production code.
Pity it didn’t get into 9.0 :) but this would be a good era to do it in.
From: EricT <tw...@gm...>
Date: Monday, October 20, 2025 at 10:05
To: da Silva, Peter J (USA) <pet...@fl...>
Cc: tc...@ro... <tc...@ro...>, tcl...@li... <tcl...@li...>, et...@ro... <et...@ro...>
Subject: Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax
Hi Peter, I sent you an email, but my email program keeps failing for some reason, so I'll repost what I said here. There's also apparently a delay in seeing the email here that caused me to reply from my home email. Yes, that is the
Hi Peter,
I sent you an email, but my email program keeps failing for some reason, so I'll repost what I said here. There's also apparently a delay in seeing the email here that caused me to reply from my home email.
Yes, that is the one known incompatibility I'm aware of. However, it is easily fixed. Please note my email to the core group on this subject. Briefly, the fix is to use the ${(index)} feature that is a compatible mechanism which can be made immediately. With the use of a pragma variable, the code could be set to throw an error for any $() usage to help track down all the unbraced usage for fixing.
Here's some testing with the feature enabled:
% set a 1
1
% set b 2
2
% set c $($a+$b)
3
% set (index) something
something
% set (index)
something
% puts ${(index)}
something
% puts $(index)
invalid bareword "index"
in expression "index";
should be "$index" or "{index}" or "index(...)" or ...
This is without implementing any pragma. So, it could already find many unbraced uses.
Regards,
Eric
On Mon, Oct 20, 2025 at 7:38 AM da Silva, Peter J <pet...@fl...<mailto:pet...@fl...>> wrote:
I recall that on one occasion when I suggested this kind of syntax I was told there was working code that used $(...) as an array index for an array whose name was the null string.
From: EricT <tw...@gm...<mailto:tw...@gm...>>
Date: Friday, October 17, 2025 at 16:23
To: tcl...@li...<mailto:tcl...@li...> <tcl...@li...<mailto:tcl...@li...>>
Cc: et...@ro...<mailto:et...@ro...> <et...@ro...<mailto:et...@ro...>>
Subject: [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
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=DwMFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=lqqkjbudEIhZyWU1Mr-DT_aw0n-0q0fJeE2A7RRQpS2HwF0EA62yINzmRaXGPetk&s=S65xARxittuq7tg4WiuXdT0ervfhA8RXzsEv3-NxhGA&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=DwMFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=npvBSAj_D_5Mhn0QfvP3wiv4K_9V-JvWDhQ08FjdHjv2zYlxUhZSH-njQBpBZtfD&s=0eGALISnuOZhdT6fGBYhKEhR9n1R8AL7z2HOBAUHnaY&e=>
|