Menu
▾
▴
tcl-core
|
From: Kevin K. <kev...@gm...> - 2025-10-21 02:31:10
|
On Mon, Oct 20, 2025 at 7:22 PM EricT <tw...@gm...> wrote:
> You're right that {=}{expression} avoids this particular incompatibility. I think {=} could potentially work, though my sense is it would require more extensive parser changes to handle quotes and bare words (where $ already works naturally). But I could be wrong about the implementation complexity.
>
>
The parser changes are pretty minimal, and nearly parallel to the
implementation of {*}. The {=} would be presumed to be followed by a
'word', with all the usual rules that implies.
{=}{$a + $b} would be parsed by the ordinary balancing of curly braces,
followed by processing the content as an expression.
{=}[command], {=}"quoted string", {=}$var, etc, would all have natural
meanings equivalent to applying [expr] to the substituted value.
(Ordinarily, those uses should be advised against, since all these forms
ask for double substitution and invite code injection attacks, but I can
see them having their place in some specialized contexts, and the syntax is
thereby rendered uniform.)
(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. But that's a different idea altogether, and has had several
rejected or abandoned TIPs over the years.)
--
73 de ke9tv/2, Kevin
|
|
From: EricT <tw...@gm...> - 2025-10-21 02:53:25
|
Kevin:
If {=} parallels {*} as you mention, does that mean it would only work as a
separate word, and not inside quoted or unquoted strings? And what about
mixing command substitutions with numerical operations.
func {=}{[string length $str] + 1}
puts "result: {=}{$x + 1}"
set x prefix{=}{$x + 1}suffix
lrange $list 0 end-{=}{$x + 2}
This is important since $(expr) works in all these contexts because $
already triggers substitution there.
Eric
On Mon, Oct 20, 2025 at 7:31 PM Kevin Kenny <kev...@gm...> wrote:
> On Mon, Oct 20, 2025 at 7:22 PM EricT <tw...@gm...> wrote:
>
>> You're right that {=}{expression} avoids this particular incompatibility. I think {=} could potentially work, though my sense is it would require more extensive parser changes to handle quotes and bare words (where $ already works naturally). But I could be wrong about the implementation complexity.
>>
>>
> The parser changes are pretty minimal, and nearly parallel to the
> implementation of {*}. The {=} would be presumed to be followed by a
> 'word', with all the usual rules that implies.
>
> {=}{$a + $b} would be parsed by the ordinary balancing of curly braces,
> followed by processing the content as an expression.
>
> {=}[command], {=}"quoted string", {=}$var, etc, would all have natural
> meanings equivalent to applying [expr] to the substituted value.
> (Ordinarily, those uses should be advised against, since all these forms
> ask for double substitution and invite code injection attacks, but I can
> see them having their place in some specialized contexts, and the syntax is
> thereby rendered uniform.)
>
> (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. But that's a different idea altogether, and has had several
> rejected or abandoned TIPs over the years.)
>
> --
> 73 de ke9tv/2, Kevin
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
|
|
From: EricT <tw...@gm...> - 2025-10-21 03:11:58
|
Thanks for the feedback, Brian! I understand your concern about the
semantic distinction between $ (value) and [ ] (execution).
I'd offer a few thoughts:
1. Shell precedent: The $(command) syntax is well-established in bash/sh
for command substitution. Tcl users familiar with shell scripting would
find this natural, not confusing.
2. $ already involves execution: Even $var involves command execution
internally (TclGetVar), it's just optimized. The distinction between "value
substitution" and "command execution" is somewhat artificial at the
implementation level.
3. expr is special and has historical precedent: Unlike arbitrary
commands, expr is used so frequently that syntactic sugar makes sense -
similar to how $var is sugar for [set var]. We optimize the common case. I
believe there was a time in early Tcl before $var existed when [set var]
was the only choice - if so, adding $var as syntactic sugar for variable
substitution was a usability win. $(expr) follows the same pattern - sugar
for the extremely common [expr {...}] case.
4. Consistency: $(expr) fits the pattern of "$ means substitute something
here" - whether a variable, array element, or expression result. Modern
languages like Python have embraced similar concepts with f-strings that
allow {expression} for inline evaluation. $(expr) brings this convenience
to Tcl while maintaining our substitution semantics.
That said, I appreciate the philosophical consistency argument. Do you see
the security benefits (auto-bracing) as compelling enough to outweigh the
semantic concern?
Did you see the email I sent you about lseq? Maybe it landed in your spam
folder - that happened once before as I recall.
Eric
On Mon, Oct 20, 2025 at 7:19 PM Brian Griffin <bri...@ea...>
wrote:
> I like the idea of simplifying expression substitutions. The problem I
> have is that the '$' is defined to be a value substitution. Running a
> command (execution) is a [] substitution, not a '$' substitution.
> Conflating the two modes of substitution can cause confusion for newbies,
> and even experienced programmers.
>
> I recognize that this view is a very subtle distinction, but I think it's
> important.
>
> Think of it like conflating * vs & in C. (Maybe not that bad, but similar)
>
> -Brian
>
> On Oct 20, 2025, at 07:22, EricT <tw...@gm...> wrote:
>
> Regarding the discussion in the telco today. If the incompatibility
> discussed is the known empty array issue, then for that I would propose the
> following:
>
> There could be a pragma or tcl_dollar_expr global variable with several
> settings.
>
> 1. Work in compatibility mode, i.e. as though the feature was not
> implemented at all.
> 2. Work in diagnostic mode, throw an error for any $(...) use
> 3. Work in full implementation mode
>
> The code to do this, given a global C variable to check would be trivial.
>
> This value could default to 1. for at least 9.1 or 9.2 but there could be
> an option, similar to tclsh -encoding, that would allow the pragma variable
> to be set before any init script code is run. This would give developers
> the opportunity to set the variable to mode 2 in order to easily track down
> uses of $(index) before any code were to begin using $(expr).
>
> I think it would be quite rare if this syntax change would affect binary
> extensions, so it should be only with script level coding.
>
> The fix to any code that is using the empty array variable, is to change
> from,
>
> set val $(index)
> set val $($var) - or any other valid index string
>
> to
>
> set val ${(index)}
> set val ${($var)}
>
> Likewise for any other use of the $(...) substitution in current use.
>
> This change can begin to be made right away, since it is a
> compatible syntax that does not change the semantics. Once all the init
> time script code or packages that use the un-braced syntax are found and
> changed, the feature could begin to be used by those who are interested.
>
> On the other hand, if the incompatibility is something other than this
> empty array, I'd be most appreciative to know what it is.
>
> thanks
>
> Eric
>
>
> On Sun, Oct 19, 2025 at 3:44 AM EricT <tw...@gm...> wrote:
>
>> Harald,
>>
>> Thank you for your willingness to sponsor!
>>
>> To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl
>> user who, in retirement, wanted to give something back to the Tcl
>> community. Jim Tcl's successful use of this syntax for years demonstrates
>> that the concept is viable.
>>
>> Regarding the telco: I attempted to join previously but was unsuccessful
>> with the setup. I won't be able to participate on Monday, but I'm available
>> via email for any questions or clarifications that arise from the
>> discussion.
>>
>> I don't currently have write access to either the Tcl Fossil repository
>> or the TIP repository, so I'm unable to make changes directly. At nearly 80
>> years old, I'm not comfortable learning new version control systems on my
>> own. If the TIP moves forward, I'd need guidance and assistance with the
>> Fossil workflow, or perhaps someone from the core team who shares our
>> interest in this TIP could handle the integration based on my GitHub
>> prototype.
>>
>> I'm currently developing a comprehensive test suite in standard tcltest
>> format, with particular focus on edge cases.
>>
>> Looking forward to hearing how Monday's discussion goes!
>>
>> Best regards,
>> Eric
>>
>>
>> On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <
>> har...@el...> wrote:
>>
>>> Eric,
>>> sponsoring is no problem. The point is to get positive votes.
>>> This requires a positive discussion.
>>> You are the Author of Jim?
>>> Could you participate on the telco on Monday?
>>>
>>> Do you have write access to the tcl fossil? We would need the
>>> implementation there.
>>>
>>> Thanks for all,
>>> Harald
>>>
>>> Am 18.10.2025 um 22:58 schrieb EricT:
>>> > Thank you for the positive feedback and for raising this in Monday's
>>> > telco! I'm encouraged by your support.
>>> >
>>> > Regarding $(a) - you're right that reading an empty array element with
>>> a
>>> > variable index is a valid construct. However, this is explicitly
>>> > addressed in the TIP and the repository README. The workarounds are
>>> > straightforward:
>>> >
>>> > ${(a)} # Braced form
>>> > [set (a)] # Command substitution
>>> >
>>> > Both still work. In fact, code using $(varname) could be proactively
>>> > modified to use ${(varname)} to indicate the clear intent of an empty
>>> > array reference, which improves readability. The security,
>>> performance,
>>> > and usability benefits of $(...) seemed to justify this trade-off for
>>> > Tcl 9.x where some incompatibilities are expected.
>>> >
>>> > Given your interest in the feature, would you be willing to consider
>>> > sponsoring TIP 672? The implementation is working and minimal (~100
>>> > lines across two files), with the main open question being the
>>> preferred
>>> > approach for tracking synthetic strings for cleanup. Your guidance on
>>> > that architectural decision would be particularly valuable.
>>> >
>>> > The prototype repository with full implementation and examples is here:
>>> >
>>> > https://github.com/rocketship88/tcl-tip-672-prototype <https://
>>> > github.com/rocketship88/tcl-tip-672-prototype>
>>> >
>>> > Looking forward to the results of the discussion on Monday! I won't be
>>> > able to join the telco discussion, but I'm available via email for any
>>> > questions or clarifications that arise.
>>> >
>>> >
>>> > On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann
>>> > <har...@el... <mailto:har...@el...>>
>>> wrote:
>>> >
>>> > Am 17.10.2025 um 23:22 schrieb EricT:
>>> > > 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://github.com/rocketship88/tcl-tip-672-prototype>
>>> > > <https://github.com/rocketship88/tcl-tip-672-prototype
>>> <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
>>> > Eric,
>>> > great proposal, thank you !
>>> >
>>> > Perhaps, we may discuss this on Monday in the biweekly telco.
>>> > I am also excited and in favor to this.
>>> > Nevertheless, "$(a)" is to my knowledge a quite common syntax for
>>> > arrays. We have already killed less disruptive proposals (see
>>> optional
>>> > "- args") by endless discussions and getting nowhere.
>>> > Hope, this will be fruitful.
>>> >
>>> > In addition, I would like to add the Tk test reform by the other
>>> > Eric to
>>> > the biweekly topics.
>>> > Here is a revised agenda proposal proposal:
>>> >
>>> > Top 1) Release calender (TIP 713)
>>> > - 9.0.3: October (2 weeks left)
>>> > - 9.1a1: November (6 weeks left)
>>> > Top 2) TIP 734 nested mutex (go or not)
>>> > Top 3) TIP 733: accessability (test status)
>>> > Top 4) TIP 732: TCL library path (discussion)
>>> > Top 5) TIP 731: use C enums (no brainer?)
>>> > Top 6) TIP 720: new bytecodes (final, great! Any issues?)
>>> > Top 7) TIP 721: Tcl_AttemptGetString
>>> > Top 8) TIP 715: supported build systems
>>> > Top 9) $($a+$b) syntax for expressions
>>> > Top 10) Tk test reform by Eric (Thanks !)
>>> > Top 11) Tcl depot and awthemes ?
>>> > Top 12) AOB
>>> > Top 13) Next meeting:
>>> > 3rd of November 12:00 UTC.
>>> > Daytime saving time ends 2nd of November in US, 26th of
>>> > October in
>>> > Europe.
>>> > Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?
>>> >
>>> > Take care,
>>> > Harald
>>> _______________________________________________
>>> 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
>
|
|
From: Zaumseil R. <RZa...@kk...> - 2025-10-21 08:36:39
|
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...>
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
|
|
From: Emiliano <emi...@gm...> - 2025-10-23 13:05:12
|
On Tue, 21 Oct 2025 08:02:55 +0000 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 > > 1. Returns only one value > > See p.e. tip 647 syntax In case you are interested, I wrote a quick POC of tip 647, available at https://chiselapp.com/user/egavilan/repository/mexpr Sample usage: # 1 argument % package require mexpr 0.1 % ::mexpr::let { a {rand()} b {3*$a} b {sqrt($b)} } 0.6664191757638097 1.9992575272914292 1.4139510342623005 % list $a $b 0.6664191757638097 1.4139510342623005 # multiple arguments % ::mexpr::let a {rand()} b {3*$a} b {sqrt($b)} 0.5070870623491178 1.5212611870473536 1.2333941734284923 % list $a $b 0.5070870623491178 1.2333941734284923 # 1 argument, using -local % unset a b % ::mexpr::let -local { a {rand()} b {3*$a} b {sqrt($b)} } 0.20174559122032745 0.6052367736609824 0.7779696482903317 list $a $b can't read "a": no such variable # with -local, all referenced variables must be either defined first # or reached using their qualified name % set c 4 4 % ::mexpr::let -local b {3 * $c} can't read "c": no such variable % ::mexpr::let -local b {3 * $::c} 12 I've left out the magic variable names; all set values are collected and returned. Feel free to change and experiment. Regards -- Emiliano |
|
From: Donal F. <don...@ma...> - 2025-10-21 08:55:20
|
EricT 2025-10-21 04:12 1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing. Surely the better shell precedent would be the $((expression)) form? That would also be quite a bit less likely to clash with existing use cases. Hmm, a quick search with https://github.com/search?q=%24%28%28+language%3ATcl&type=code gives 29 hits (most of which appear to be false positives; the real hits seem to be from one place in JimTcl itself), as opposed to 4k hits when looking for $( in Tcl code; two orders of magnitude less usage. One of the really nice things about a resource like GitHub is that one can quickly search for language syntax features across a lot of code and get a good feeling for practical compatibility. While $(([llength $x] - 17)) is no shorter than {=}{[llength $x] - 17}, it's definitely easier to type! (Eric: Don't lose heart! These discussions are a lot less acrimonious than the discussion over what became {*} was.) Donal. ________________________________ From: EricT <tw...@gm...> Sent: Tuesday, October 21, 2025 04:11 To: Brian Griffin <bri...@ea...> Cc: tc...@ro... <tc...@ro...>; Tcl Core List <tcl...@li...> Subject: Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax Thanks for the feedback, Brian! I understand your concern about the semantic distinction between $ (value) and [ ] (execution). I'd offer a few thoughts: 1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing. 2. $ already involves execution: Even $var involves command execution internally (TclGetVar), it's just optimized. The distinction between "value substitution" and "command execution" is somewhat artificial at the implementation level. 3. expr is special and has historical precedent: Unlike arbitrary commands, expr is used so frequently that syntactic sugar makes sense - similar to how $var is sugar for [set var]. We optimize the common case. I believe there was a time in early Tcl before $var existed when [set var] was the only choice - if so, adding $var as syntactic sugar for variable substitution was a usability win. $(expr) follows the same pattern - sugar for the extremely common [expr {...}] case. 4. Consistency: $(expr) fits the pattern of "$ means substitute something here" - whether a variable, array element, or expression result. Modern languages like Python have embraced similar concepts with f-strings that allow {expression} for inline evaluation. $(expr) brings this convenience to Tcl while maintaining our substitution semantics. That said, I appreciate the philosophical consistency argument. Do you see the security benefits (auto-bracing) as compelling enough to outweigh the semantic concern? Did you see the email I sent you about lseq? Maybe it landed in your spam folder - that happened once before as I recall. Eric On Mon, Oct 20, 2025 at 7:19 PM Brian Griffin <bri...@ea...<mailto:bri...@ea...>> wrote: I like the idea of simplifying expression substitutions. The problem I have is that the '$' is defined to be a value substitution. Running a command (execution) is a [] substitution, not a '$' substitution. Conflating the two modes of substitution can cause confusion for newbies, and even experienced programmers. I recognize that this view is a very subtle distinction, but I think it's important. Think of it like conflating * vs & in C. (Maybe not that bad, but similar) -Brian On Oct 20, 2025, at 07:22, EricT <tw...@gm...<mailto:tw...@gm...>> wrote: Regarding the discussion in the telco today. If the incompatibility discussed is the known empty array issue, then for that I would propose the following: There could be a pragma or tcl_dollar_expr global variable with several settings. 1. Work in compatibility mode, i.e. as though the feature was not implemented at all. 2. Work in diagnostic mode, throw an error for any $(...) use 3. Work in full implementation mode The code to do this, given a global C variable to check would be trivial. This value could default to 1. for at least 9.1 or 9.2 but there could be an option, similar to tclsh -encoding, that would allow the pragma variable to be set before any init script code is run. This would give developers the opportunity to set the variable to mode 2 in order to easily track down uses of $(index) before any code were to begin using $(expr). I think it would be quite rare if this syntax change would affect binary extensions, so it should be only with script level coding. The fix to any code that is using the empty array variable, is to change from, set val $(index) set val $($var) - or any other valid index string to set val ${(index)} set val ${($var)} Likewise for any other use of the $(...) substitution in current use. This change can begin to be made right away, since it is a compatible syntax that does not change the semantics. Once all the init time script code or packages that use the un-braced syntax are found and changed, the feature could begin to be used by those who are interested. On the other hand, if the incompatibility is something other than this empty array, I'd be most appreciative to know what it is. thanks Eric On Sun, Oct 19, 2025 at 3:44 AM EricT <tw...@gm...<mailto:tw...@gm...>> wrote: Harald, Thank you for your willingness to sponsor! To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl user who, in retirement, wanted to give something back to the Tcl community. Jim Tcl's successful use of this syntax for years demonstrates that the concept is viable. Regarding the telco: I attempted to join previously but was unsuccessful with the setup. I won't be able to participate on Monday, but I'm available via email for any questions or clarifications that arise from the discussion. I don't currently have write access to either the Tcl Fossil repository or the TIP repository, so I'm unable to make changes directly. At nearly 80 years old, I'm not comfortable learning new version control systems on my own. If the TIP moves forward, I'd need guidance and assistance with the Fossil workflow, or perhaps someone from the core team who shares our interest in this TIP could handle the integration based on my GitHub prototype. I'm currently developing a comprehensive test suite in standard tcltest format, with particular focus on edge cases. Looking forward to hearing how Monday's discussion goes! Best regards, Eric On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <har...@el...<mailto:har...@el...>> wrote: Eric, sponsoring is no problem. The point is to get positive votes. This requires a positive discussion. You are the Author of Jim? Could you participate on the telco on Monday? Do you have write access to the tcl fossil? We would need the implementation there. Thanks for all, Harald Am 18.10.2025 um 22:58 schrieb EricT: > Thank you for the positive feedback and for raising this in Monday's > telco! I'm encouraged by your support. > > Regarding $(a) - you're right that reading an empty array element with a > variable index is a valid construct. However, this is explicitly > addressed in the TIP and the repository README. The workarounds are > straightforward: > > ${(a)} # Braced form > [set (a)] # Command substitution > > Both still work. In fact, code using $(varname) could be proactively > modified to use ${(varname)} to indicate the clear intent of an empty > array reference, which improves readability. The security, performance, > and usability benefits of $(...) seemed to justify this trade-off for > Tcl 9.x where some incompatibilities are expected. > > Given your interest in the feature, would you be willing to consider > sponsoring TIP 672? The implementation is working and minimal (~100 > lines across two files), with the main open question being the preferred > approach for tracking synthetic strings for cleanup. Your guidance on > that architectural decision would be particularly valuable. > > The prototype repository with full implementation and examples is here: > > https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$> <https:// > github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>> > > Looking forward to the results of the discussion on Monday! I won't be > able to join the telco discussion, but I'm available via email for any > questions or clarifications that arise. > > > On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann > <har...@el...<mailto:har...@el...> <mailto:har...@el...<mailto:har...@el...>>> wrote: > > Am 17.10.2025 um 23:22 schrieb EricT: > > 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 [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$> > <https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>> > > <https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$> <https:// > github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>>> > > > > 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 > Eric, > great proposal, thank you ! > > Perhaps, we may discuss this on Monday in the biweekly telco. > I am also excited and in favor to this. > Nevertheless, "$(a)" is to my knowledge a quite common syntax for > arrays. We have already killed less disruptive proposals (see optional > "- args") by endless discussions and getting nowhere. > Hope, this will be fruitful. > > In addition, I would like to add the Tk test reform by the other > Eric to > the biweekly topics. > Here is a revised agenda proposal proposal: > > Top 1) Release calender (TIP 713) > - 9.0.3: October (2 weeks left) > - 9.1a1: November (6 weeks left) > Top 2) TIP 734 nested mutex (go or not) > Top 3) TIP 733: accessability (test status) > Top 4) TIP 732: TCL library path (discussion) > Top 5) TIP 731: use C enums (no brainer?) > Top 6) TIP 720: new bytecodes (final, great! Any issues?) > Top 7) TIP 721: Tcl_AttemptGetString > Top 8) TIP 715: supported build systems > Top 9) $($a+$b) syntax for expressions > Top 10) Tk test reform by Eric (Thanks !) > Top 11) Tcl depot and awthemes ? > Top 12) AOB > Top 13) Next meeting: > 3rd of November 12:00 UTC. > Daytime saving time ends 2nd of November in US, 26th of > October in > Europe. > Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM? > > Take care, > Harald _______________________________________________ Tcl-Core mailing list Tcl...@li...<mailto:Tcl...@li...> https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$> _______________________________________________ Tcl-Core mailing list Tcl...@li...<mailto:Tcl...@li...> https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$> _______________________________________________ Tcl-Core mailing list Tcl...@li...<mailto:Tcl...@li...> https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$> |
|
From: bch <bra...@gm...> - 2025-10-24 06:36:07
|
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Oct 21, 2025, at 01:55, Donal Fellows <don...@ma...> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <div class="_E_EBlockEntityContainer"><span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Helvetica Neue", sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="entityDelimiterBefore"></span> <div style="width: 100%; display: inline-block;" class="_Entity _EType_Quote _EId_Quote _EReadonly_1"> <table id="ReplyWithQuote_Container" style="border: 1.5px solid rgb(237, 235, 233); border-radius: 4px; padding: 4px 0px 4px 4px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); margin-bottom: 4px;"> <tbody> <tr> <td rowspan="2" style="background-color: rgb(200, 198, 196); width: 3.5px; border-radius: 10px; padding: 0px;"> </td> <td style="font-size: 12px; border-left: 10px solid transparent; border-right: 10px solid transparent; padding: 0px;"> <div style="display: inline; color: rgb(50, 49, 48);">EricT</div> <div style="display: inline; padding-left: 10px; color: rgb(96, 94, 92);">2025-10-21 04:12</div> </td> </tr> <tr> <td style="font-size: 14px; color: rgb(50, 49, 48); border-left: 10px solid transparent; border-right: 10px solid transparent; padding: 0px;"> 1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.</td> </tr> </tbody> </table> </div> <span style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Helvetica Neue", sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="entityDelimiterAfter"></span></div> <div style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Helvetica Neue", sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="elementToProof"> Surely the better shell precedent would be the $((expression)) form? </div></div></blockquote><div><br></div><div><br></div><div>Fwiw, I don’t think looking up to bash/sh for inspiration is where we should be at all. We can do better for Tcl, regardless of how familiar it looks.</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div style="font-family: "Segoe UI", "Segoe UI Web (West European)", "Helvetica Neue", sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="elementToProof">That would also be quite a bit less likely to clash with existing use cases.<span style="color: rgb(0, 0, 0);"> Hmm, a quick search with <a href="https://github.com/search?q=%24%28%28+language%3ATcl&type=code">https://github.com/search?q=%24%28%28+language%3ATcl&type=code</a> gives 29 hits (most of which appear to be false positives; the real hits seem to be from one place in JimTcl itself), as opposed to 4k hits when looking for $( in Tcl code; two orders of magnitude less usage. One of the <i>really</i> nice things about a resource like GitHub is that one can <i>quickly</i> search for language syntax features across a lot of code and get a good feeling for practical compatibility.</span></div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> <br> </div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> While $(([llength $x] - 17)) is no shorter than {=}{[llength $x] - 17}, it's definitely easier to type!</div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> <br></div></div></blockquote><div><br></div><div>I already deal enough w [expr] that it’s not a big deal… but *imagining* typing either of the above, if I had to pick, I think I’d prefer Brian’s modification for the reason of the benefits pointed out by him and Kevin wrt “{*}” precedent in scripts and its adaptable parser implementation.</div><div><br></div><div>“Fixing” empty array w pragmas or similar is also not attractive sounding… it means it’s difficult to know what kind of runtime you’re stepping up to. At its worst, it leads to inscrutable envs like php.ini. This is a thin edge of the wedge we should be looking to avoid.</div><br><blockquote type="cite"><div dir="ltr"><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> </div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> (Eric: Don't lose heart! These discussions are a <i>lot</i> less acrimonious than the discussion over what became {*} was.) </div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> <br> </div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> Donal.</div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof"> <br> </div> <hr style="display: inline-block; width: 98%;"> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <b>From:</b> EricT <tw...@gm...><br> <b>Sent:</b> Tuesday, October 21, 2025 04:11<br> <b>To:</b> Brian Griffin <bri...@ea...><br> <b>Cc:</b> tc...@ro... <tc...@ro...>; Tcl Core List <tcl...@li...><br> <b>Subject:</b> Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax </div> <div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <br> </div> <div style="direction: ltr;">Thanks for the feedback, Brian! I understand your concern about the semantic distinction between $ (value) and [ ] (execution).<br> <br> I'd offer a few thoughts:<br> <br> 1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.<br> <br> 2. $ already involves execution: Even $var involves command execution internally (TclGetVar), it's just optimized. The distinction between "value substitution" and "command execution" is somewhat artificial at the implementation level.<br> <br> 3. expr is special and has historical precedent: Unlike arbitrary commands, expr is used so frequently that syntactic sugar makes sense - similar to how $var is sugar for [set var]. We optimize the common case. I believe there was a time in early Tcl before $var existed when [set var] was the only choice - if so, adding $var as syntactic sugar for variable substitution was a usability win. $(expr) follows the same pattern - sugar for the extremely common [expr {...}] case.<br> <br> 4. Consistency: $(expr) fits the pattern of "$ means substitute something here" - whether a variable, array element, or expression result. Modern languages like Python have embraced similar concepts with f-strings that allow {expression} for inline evaluation. $(expr) brings this convenience to Tcl while maintaining our substitution semantics.<br> <br> That said, I appreciate the philosophical consistency argument. Do you see the security benefits (auto-bracing) as compelling enough to outweigh the semantic concern?<br> <br> </div> <div style="direction: ltr;">Did you see the email I sent you about lseq? Maybe it landed in your spam folder - that happened once before as I recall.</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">Eric</div> <div style="direction: ltr;"><br> </div> <div><br> </div> <div style="direction: ltr;">On Mon, Oct 20, 2025 at 7:19 PM Brian Griffin <<a class="OWAAutoLink" id="OWA804178ca-19c0-2c1c-f2ba-089dcc6f3e84" href="mailto:bri...@ea...">bri...@ea...</a>> wrote:</div> <blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);"> <div>I like the idea of simplifying expression substitutions. The problem I have is that the '$' is defined to be a value substitution. Running a command (execution) is a [] substitution, not a '$' substitution. Conflating the two modes of substitution can cause confusion for newbies, and even experienced programmers. </div> <div><br> </div> <div>I recognize that this view is a very subtle distinction, but I think it's important.</div> <div><br> </div> <div>Think of it like conflating * vs & in C. (Maybe not that bad, but similar)</div> <div><br> </div> <div>-Brian</div> <div><br> </div> <blockquote> <div>On Oct 20, 2025, at 07:22, EricT <<a class="OWAAutoLink" id="OWA485216db-5c80-ecb7-38fe-a224c563294c" href="mailto:tw...@gm...">tw...@gm...</a>> wrote:</div> <div><br> </div> <div style="direction: ltr;">Regarding the discussion in the telco today. If the incompatibility discussed is the known empty array issue, then for that I would propose the following:</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">There could be a pragma or tcl_dollar_expr global variable with several settings.</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">1. Work in compatibility mode, i.e. as though the feature was not implemented at all. </div> <div style="direction: ltr;">2. Work in diagnostic mode, throw an error for any $(...) use</div> <div style="direction: ltr;">3. Work in full implementation mode</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">The code to do this, given a global C variable to check would be trivial. </div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">This value could default to 1. for at least 9.1 or 9.2 but there could be an option, similar to tclsh -encoding, that would allow the pragma variable to be set before any init script code is run. This would give developers the opportunity to set the variable to mode 2 in order to easily track down uses of $(index) before any code were to begin using $(expr). </div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">I think it would be quite rare if this syntax change would affect binary extensions, so it should be only with script level coding. </div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">The fix to any code that is using the empty array variable, is to change from,</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;"> set val $(index)</div> <div style="direction: ltr;"> set val $($var) - or any other valid index string</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">to</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;"> set val ${(index)}</div> <div style="direction: ltr;"> set val ${($var)}</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">Likewise for any other use of the $(...) substitution in current use.</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">This change can begin to be made right away, since it is a compatible syntax that does not change the semantics. Once all the init time script code or packages that use the un-braced syntax are found and changed, the feature could begin to be used by those who are interested.</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">On the other hand, if the incompatibility is something other than this empty array, I'd be most appreciative to know what it is.</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">thanks</div> <div style="direction: ltr;"><br> </div> <div style="direction: ltr;">Eric</div> <div style="direction: ltr;"><br> </div> <div><br> </div> <div style="direction: ltr;">On Sun, Oct 19, 2025 at 3:44 AM EricT <<a class="OWAAutoLink" id="OWA0301b487-6449-46f4-f565-a768f03d4ed8" href="mailto:tw...@gm...">tw...@gm...</a>> wrote:</div> <blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);"> <div style="direction: ltr;">Harald,<br> <br> Thank you for your willingness to sponsor!<br> <br> To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl user who, in retirement, wanted to give something back to the Tcl community. Jim Tcl's successful use of this syntax for years demonstrates that the concept is viable.<br> <br> Regarding the telco: I attempted to join previously but was unsuccessful with the setup. I won't be able to participate on Monday, but I'm available via email for any questions or clarifications that arise from the discussion.<br> <br> I don't currently have write access to either the Tcl Fossil repository or the TIP repository, so I'm unable to make changes directly. At nearly 80 years old, I'm not comfortable learning new version control systems on my own. If the TIP moves forward, I'd need guidance and assistance with the Fossil workflow, or perhaps someone from the core team who shares our interest in this TIP could handle the integration based on my GitHub prototype.<br> <br> I'm currently developing a comprehensive test suite in standard tcltest format, with particular focus on edge cases.<br> <br> Looking forward to hearing how Monday's discussion goes!<br> <br> Best regards,<br> Eric<br> <br> </div> <div><br> </div> <div style="direction: ltr;">On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <<a class="OWAAutoLink" id="OWA2fbb6158-6c45-6109-517a-ee2f2e870a8d" href="mailto:har...@el...">har...@el...</a>> wrote:</div> <blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);"> <div>Eric,<br> sponsoring is no problem. The point is to get positive votes.<br> This requires a positive discussion.<br> You are the Author of Jim?<br> Could you participate on the telco on Monday?<br> <br> Do you have write access to the tcl fossil? We would need the<br> implementation there.<br> <br> Thanks for all,<br> Harald<br> <br> Am 18.10.2025 um 22:58 schrieb EricT:<br> > Thank you for the positive feedback and for raising this in Monday's<br> > telco! I'm encouraged by your support.<br> ><br> > Regarding $(a) - you're right that reading an empty array element with a<br> > variable index is a valid construct. However, this is explicitly<br> > addressed in the TIP and the repository README. The workarounds are<br> > straightforward:<br> ><br> > ${(a)} # Braced form<br> > [set (a)] # Command substitution<br> ><br> > Both still work. In fact, code using $(varname) could be proactively<br> > modified to use ${(varname)} to indicate the clear intent of an empty<br> > array reference, which improves readability. The security, performance,<br> > and usability benefits of $(...) seemed to justify this trade-off for<br> > Tcl 9.x where some incompatibilities are expected.<br> ><br> > Given your interest in the feature, would you be willing to consider<br> > sponsoring TIP 672? The implementation is working and minimal (~100<br> > lines across two files), with the main open question being the preferred<br> > approach for tracking synthetic strings for cleanup. Your guidance on<br> > that architectural decision would be particularly valuable.<br> ><br> > The prototype repository with full implementation and examples is here:<br> ><br> > <a data-auth="NotApplicable" class="OWAAutoLink" id="OWAdaeb721a-2f2d-fd46-b16d-f7f9fa85487c" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$"> https://github.com/rocketship88/tcl-tip-672-prototype [github.com]</a> <https://<br> > <a data-auth="NotApplicable" class="OWAAutoLink" id="OWA1c08f87f-3e1b-7345-47d1-f83e958ed390" href="https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$"> github.com/rocketship88/tcl-tip-672-prototype [github.com]</a>><br> ><br> > Looking forward to the results of the discussion on Monday! I won't be<br> > able to join the telco discussion, but I'm available via email for any<br> > questions or clarifications that arise.<br> ><br> ><br> > On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann<br> > <<a class="OWAAutoLink" id="OWAd5fa5ee4-6688-a096-b39b-58044e2e7260" href="mailto:har...@el...">har...@el...</a> <mailto:<a class="OWAAutoLink" id="OWAf2861fb4-1b96-a647-8bf1-afd401700057" href="mailto:har...@el...">har...@el...</a>>> wrote:<br> ><br> > Am 17.10.2025 um 23:22 schrieb EricT:<br> > > Hello Tcl Core Team,<br> > ><br> > > I have developed a working prototype implementation of TIP 672,<br> > which<br> > > adds the $(expression) syntax as a more intuitive alternative to<br> > [expr<br> > > {expression}].<br> > ><br> > > Repository: <a data-auth="NotApplicable" class="OWAAutoLink" id="OWAce957dfa-015b-f49e-7f83-9d4c46409d16" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$"> https://github.com/rocketship88/tcl-tip-672-prototype [github.com]</a><br> > <<a data-auth="NotApplicable" class="OWAAutoLink" id="OWA94372cbc-677c-140b-b1b9-19e6a24a6c78" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$">https://github.com/rocketship88/tcl-tip-672-prototype [github.com]</a>><br> > > <<a data-auth="NotApplicable" class="OWAAutoLink" id="OWA40bf9571-1dc9-0b4c-1210-7d004ffe86fc" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$">https://github.com/rocketship88/tcl-tip-672-prototype [github.com]</a> <https://<br> > <a data-auth="NotApplicable" class="OWAAutoLink" id="OWAbd5aac6c-e012-89e6-4559-05a1150d33b2" href="https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$">github.com/rocketship88/tcl-tip-672-prototype [github.com]</a>>><br> > ><br> > > The implementation is minimal, modifying only two files<br> > (tclParse.c and<br> > > tclNamesp.c) with approximately 100 lines of changes. The key<br> > > modification converts the existing two-way branch in<br> > Tcl_ParseVarName to<br> > > a three-way branch, with the new path handling $(...) by creating a<br> > > synthetic [expr {...}] command string.<br> > ><br> > > Key Accomplishments:<br> > ><br> > > Full bytecode compilation: The synthetic string approach integrates<br> > > seamlessly with the existing compiler, producing identical optimized<br> > > bytecode as [expr {...}]. The disassembler output (shown in the<br> > README)<br> > > demonstrates efficient variable loading with no runtime parsing<br> > overhead.<br> > ><br> > > Proven approach: Jim Tcl has used this syntax successfully for years<br> > ><br> > > Comprehensive testing: Works correctly with string interpolation,<br> > > variable scoping, error handling, and interactive mode<br> > ><br> > > Known Limitations:<br> > ><br> > > Memory leak: The synthetic string is allocated but not tracked for<br> > > cleanup in Tcl_FreeParse. This requires core team guidance on the<br> > > preferred solution (modify Tcl_Parse structure vs. thread-local<br> > tracking).<br> > ><br> > > Error messages: Currently show the synthetic command rather than the<br> > > original $(...) syntax, though this is arguably helpful for<br> > debugging.<br> > ><br> > > Questions for the Team:<br> > ><br> > > What is the preferred approach for tracking synthetic strings for<br> > cleanup?<br> > > Is this prototype architecture acceptable for Tcl 9.x?<br> > > Are there concerns with the synthetic string approach that I<br> > should address?<br> > ><br> > > The complete implementation with side-by-side diffs is available<br> > in the<br> > > repository. I'm happy to refine the code based on your feedback and<br> > > would appreciate any guidance on moving this forward.<br> > ><br> > > Best regards,<br> > > Eric<br> > Eric,<br> > great proposal, thank you !<br> ><br> > Perhaps, we may discuss this on Monday in the biweekly telco.<br> > I am also excited and in favor to this.<br> > Nevertheless, "$(a)" is to my knowledge a quite common syntax for<br> > arrays. We have already killed less disruptive proposals (see optional<br> > "- args") by endless discussions and getting nowhere.<br> > Hope, this will be fruitful.<br> ><br> > In addition, I would like to add the Tk test reform by the other<br> > Eric to<br> > the biweekly topics.<br> > Here is a revised agenda proposal proposal:<br> ><br> > Top 1) Release calender (TIP 713)<br> > - 9.0.3: October (2 weeks left)<br> > - 9.1a1: November (6 weeks left)<br> > Top 2) TIP 734 nested mutex (go or not)<br> > Top 3) TIP 733: accessability (test status)<br> > Top 4) TIP 732: TCL library path (discussion)<br> > Top 5) TIP 731: use C enums (no brainer?)<br> > Top 6) TIP 720: new bytecodes (final, great! Any issues?)<br> > Top 7) TIP 721: Tcl_AttemptGetString<br> > Top 8) TIP 715: supported build systems<br> > Top 9) $($a+$b) syntax for expressions<br> > Top 10) Tk test reform by Eric (Thanks !)<br> > Top 11) Tcl depot and awthemes ?<br> > Top 12) AOB<br> > Top 13) Next meeting:<br> > 3rd of November 12:00 UTC.<br> > Daytime saving time ends 2nd of November in US, 26th of<br> > October in<br> > Europe.<br> > Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?<br> ><br> > Take care,<br> > Harald<br> _______________________________________________<br> Tcl-Core mailing list<br> <a class="OWAAutoLink" id="OWAf1cd5ec3-5d97-fbde-0c52-b7c698f69775" href="mailto:Tcl...@li...">Tcl...@li...</a><br> <a data-auth="NotApplicable" class="OWAAutoLink" id="OWAa4f4fc9a-55e5-a33e-f0a7-08748655b707" href="https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$">https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]</a></div> </blockquote> </blockquote> <div>_______________________________________________<br> Tcl-Core mailing list<br> <a class="OWAAutoLink" id="OWAf7715aa5-657f-5210-174d-19047f1ff76e" href="mailto:Tcl...@li...">Tcl...@li...</a><br> <a data-auth="NotApplicable" class="OWAAutoLink" id="OWA379eb571-ba61-7a7c-a12f-00064b6d4c0d" href="https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$">https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]</a></div> </blockquote> <div><br> </div> <div>_______________________________________________<br> Tcl-Core mailing list<br> <a class="OWAAutoLink" id="OWA03fcfbd3-f104-e894-3393-012223471655" href="mailto:Tcl...@li...">Tcl...@li...</a><br> <a data-auth="NotApplicable" class="OWAAutoLink" id="OWA370068aa-2027-2f72-9d23-2e57871abfcd" href="https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$">https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]</a></div> </blockquote> <span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span>Tcl...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/tcl-core</span><br></div></blockquote></body></html> |
|
From: EricT <tw...@gm...> - 2025-10-21 12:36:25
|
Hi Donal:
Yes, I should have been more careful with that. I see that it is actually
$((...)) in bash.
I think the best approach is to find all the uses by both searching and
also a pragma that optionally will cause any use of $() to be flagged with
an error. Then convert to using one of the two alternative methods.
I understand empty array names exist in production code. It's also
important to note that ${()} doesn't work for all cases - it only handles
literal indices. When the index involves variable substitution (like
$($var)), users must use [set (...)] instead.
The migration path is clear I believe: use [set (...)] which works for all
cases, both before and after the feature is enabled.
Thanks again for the feedback.
Eric
On Tue, Oct 21, 2025 at 1:55 AM Donal Fellows <
don...@ma...> wrote:
>
> EricT
> 2025-10-21 04:12
> 1. Shell precedent: The $(command) syntax is well-established in bash/sh
> for command substitution. Tcl users familiar with shell scripting would
> find this natural, not confusing.
>
> Surely the better shell precedent would be the $((expression)) form? That
> would also be quite a bit less likely to clash with existing use cases. Hmm,
> a quick search with
> https://github.com/search?q=%24%28%28+language%3ATcl&type=code gives 29
> hits (most of which appear to be false positives; the real hits seem to be
> from one place in JimTcl itself), as opposed to 4k hits when looking for $(
> in Tcl code; two orders of magnitude less usage. One of the *really* nice
> things about a resource like GitHub is that one can *quickly* search for
> language syntax features across a lot of code and get a good feeling for
> practical compatibility.
>
> While $(([llength $x] - 17)) is no shorter than {=}{[llength $x] - 17},
> it's definitely easier to type!
>
> (Eric: Don't lose heart! These discussions are a *lot* less acrimonious
> than the discussion over what became {*} was.)
>
> Donal.
>
> ------------------------------
> *From:* EricT <tw...@gm...>
> *Sent:* Tuesday, October 21, 2025 04:11
> *To:* Brian Griffin <bri...@ea...>
> *Cc:* tc...@ro... <tc...@ro...>; Tcl Core List <
> tcl...@li...>
> *Subject:* Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr)
> Syntax
>
> Thanks for the feedback, Brian! I understand your concern about the
> semantic distinction between $ (value) and [ ] (execution).
>
> I'd offer a few thoughts:
>
> 1. Shell precedent: The $(command) syntax is well-established in bash/sh
> for command substitution. Tcl users familiar with shell scripting would
> find this natural, not confusing.
>
> 2. $ already involves execution: Even $var involves command execution
> internally (TclGetVar), it's just optimized. The distinction between "value
> substitution" and "command execution" is somewhat artificial at the
> implementation level.
>
> 3. expr is special and has historical precedent: Unlike arbitrary
> commands, expr is used so frequently that syntactic sugar makes sense -
> similar to how $var is sugar for [set var]. We optimize the common case. I
> believe there was a time in early Tcl before $var existed when [set var]
> was the only choice - if so, adding $var as syntactic sugar for variable
> substitution was a usability win. $(expr) follows the same pattern - sugar
> for the extremely common [expr {...}] case.
>
> 4. Consistency: $(expr) fits the pattern of "$ means substitute something
> here" - whether a variable, array element, or expression result. Modern
> languages like Python have embraced similar concepts with f-strings that
> allow {expression} for inline evaluation. $(expr) brings this convenience
> to Tcl while maintaining our substitution semantics.
>
> That said, I appreciate the philosophical consistency argument. Do you see
> the security benefits (auto-bracing) as compelling enough to outweigh the
> semantic concern?
>
> Did you see the email I sent you about lseq? Maybe it landed in your spam
> folder - that happened once before as I recall.
>
> Eric
>
>
> On Mon, Oct 20, 2025 at 7:19 PM Brian Griffin <bri...@ea...>
> wrote:
>
> I like the idea of simplifying expression substitutions. The problem I
> have is that the '$' is defined to be a value substitution. Running a
> command (execution) is a [] substitution, not a '$' substitution.
> Conflating the two modes of substitution can cause confusion for newbies,
> and even experienced programmers.
>
> I recognize that this view is a very subtle distinction, but I think it's
> important.
>
> Think of it like conflating * vs & in C. (Maybe not that bad, but similar)
>
> -Brian
>
> On Oct 20, 2025, at 07:22, EricT <tw...@gm...> wrote:
>
> Regarding the discussion in the telco today. If the incompatibility
> discussed is the known empty array issue, then for that I would propose the
> following:
>
> There could be a pragma or tcl_dollar_expr global variable with several
> settings.
>
> 1. Work in compatibility mode, i.e. as though the feature was not
> implemented at all.
> 2. Work in diagnostic mode, throw an error for any $(...) use
> 3. Work in full implementation mode
>
> The code to do this, given a global C variable to check would be trivial.
>
> This value could default to 1. for at least 9.1 or 9.2 but there could be
> an option, similar to tclsh -encoding, that would allow the pragma variable
> to be set before any init script code is run. This would give developers
> the opportunity to set the variable to mode 2 in order to easily track down
> uses of $(index) before any code were to begin using $(expr).
>
> I think it would be quite rare if this syntax change would affect binary
> extensions, so it should be only with script level coding.
>
> The fix to any code that is using the empty array variable, is to change
> from,
>
> set val $(index)
> set val $($var) - or any other valid index string
>
> to
>
> set val ${(index)}
> set val ${($var)}
>
> Likewise for any other use of the $(...) substitution in current use.
>
> This change can begin to be made right away, since it is a
> compatible syntax that does not change the semantics. Once all the init
> time script code or packages that use the un-braced syntax are found and
> changed, the feature could begin to be used by those who are interested.
>
> On the other hand, if the incompatibility is something other than this
> empty array, I'd be most appreciative to know what it is.
>
> thanks
>
> Eric
>
>
> On Sun, Oct 19, 2025 at 3:44 AM EricT <tw...@gm...> wrote:
>
> Harald,
>
> Thank you for your willingness to sponsor!
>
> To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl user
> who, in retirement, wanted to give something back to the Tcl community. Jim
> Tcl's successful use of this syntax for years demonstrates that the concept
> is viable.
>
> Regarding the telco: I attempted to join previously but was unsuccessful
> with the setup. I won't be able to participate on Monday, but I'm available
> via email for any questions or clarifications that arise from the
> discussion.
>
> I don't currently have write access to either the Tcl Fossil repository or
> the TIP repository, so I'm unable to make changes directly. At nearly 80
> years old, I'm not comfortable learning new version control systems on my
> own. If the TIP moves forward, I'd need guidance and assistance with the
> Fossil workflow, or perhaps someone from the core team who shares our
> interest in this TIP could handle the integration based on my GitHub
> prototype.
>
> I'm currently developing a comprehensive test suite in standard tcltest
> format, with particular focus on edge cases.
>
> Looking forward to hearing how Monday's discussion goes!
>
> Best regards,
> Eric
>
>
> On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <
> har...@el...> wrote:
>
> Eric,
> sponsoring is no problem. The point is to get positive votes.
> This requires a positive discussion.
> You are the Author of Jim?
> Could you participate on the telco on Monday?
>
> Do you have write access to the tcl fossil? We would need the
> implementation there.
>
> Thanks for all,
> Harald
>
> Am 18.10.2025 um 22:58 schrieb EricT:
> > Thank you for the positive feedback and for raising this in Monday's
> > telco! I'm encouraged by your support.
> >
> > Regarding $(a) - you're right that reading an empty array element with a
> > variable index is a valid construct. However, this is explicitly
> > addressed in the TIP and the repository README. The workarounds are
> > straightforward:
> >
> > ${(a)} # Braced form
> > [set (a)] # Command substitution
> >
> > Both still work. In fact, code using $(varname) could be proactively
> > modified to use ${(varname)} to indicate the clear intent of an empty
> > array reference, which improves readability. The security, performance,
> > and usability benefits of $(...) seemed to justify this trade-off for
> > Tcl 9.x where some incompatibilities are expected.
> >
> > Given your interest in the feature, would you be willing to consider
> > sponsoring TIP 672? The implementation is working and minimal (~100
> > lines across two files), with the main open question being the preferred
> > approach for tracking synthetic strings for cleanup. Your guidance on
> > that architectural decision would be particularly valuable.
> >
> > The prototype repository with full implementation and examples is here:
> >
> > https://github.com/rocketship88/tcl-tip-672-prototype [github.com]
> <https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>
> <https://
> > github.com/rocketship88/tcl-tip-672-prototype [github.com]
> <https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>
> >
> >
> > Looking forward to the results of the discussion on Monday! I won't be
> > able to join the telco discussion, but I'm available via email for any
> > questions or clarifications that arise.
> >
> >
> > On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann
> > <har...@el... <mailto:har...@el...>>
> wrote:
> >
> > Am 17.10.2025 um 23:22 schrieb EricT:
> > > 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
> [github.com]
> <https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>
> > <https://github.com/rocketship88/tcl-tip-672-prototype [github.com]
> <https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>
> >
> > > <https://github.com/rocketship88/tcl-tip-672-prototype
> [github.com]
> <https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>
> <https://
> > github.com/rocketship88/tcl-tip-672-prototype [github.com]
> <https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>
> >>
> > >
> > > 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
> > Eric,
> > great proposal, thank you !
> >
> > Perhaps, we may discuss this on Monday in the biweekly telco.
> > I am also excited and in favor to this.
> > Nevertheless, "$(a)" is to my knowledge a quite common syntax for
> > arrays. We have already killed less disruptive proposals (see
> optional
> > "- args") by endless discussions and getting nowhere.
> > Hope, this will be fruitful.
> >
> > In addition, I would like to add the Tk test reform by the other
> > Eric to
> > the biweekly topics.
> > Here is a revised agenda proposal proposal:
> >
> > Top 1) Release calender (TIP 713)
> > - 9.0.3: October (2 weeks left)
> > - 9.1a1: November (6 weeks left)
> > Top 2) TIP 734 nested mutex (go or not)
> > Top 3) TIP 733: accessability (test status)
> > Top 4) TIP 732: TCL library path (discussion)
> > Top 5) TIP 731: use C enums (no brainer?)
> > Top 6) TIP 720: new bytecodes (final, great! Any issues?)
> > Top 7) TIP 721: Tcl_AttemptGetString
> > Top 8) TIP 715: supported build systems
> > Top 9) $($a+$b) syntax for expressions
> > Top 10) Tk test reform by Eric (Thanks !)
> > Top 11) Tcl depot and awthemes ?
> > Top 12) AOB
> > Top 13) Next meeting:
> > 3rd of November 12:00 UTC.
> > Daytime saving time ends 2nd of November in US, 26th of
> > October in
> > Europe.
> > Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?
> >
> > Take care,
> > Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> [lists.sourceforge.net]
> <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> [lists.sourceforge.net]
> <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> [lists.sourceforge.net]
> <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
|
|
From: Donal F. <don...@ma...> - 2025-10-23 11:16:18
|
[Hmm, looks like I forget to send this...]
My point was severalfold:
1.
The shell syntax had double-parenthesis.
2.
A search for that exact syntax in Tcl code yielded almost no valid results; only JimTcl code appears to be currently affected. The search was only of code that's public, but that acts as a sampler for the space of non-public code.
3.
The syntax $((...)) is therefore concluded to be available whereas the shorter $(...) syntax is contested; we're talking about two or three orders of magnitude more instances. That's going to be significant migration trouble. Nobody appears to be using literal array keys that start and end with parentheses in practice.
*
The cases where they're using keys which contain them and are using an empty-named array don't count; the syntax must be starting with exactly $(( or $( for the syntax to trigger
*
Updating the implementation proposed syntax (plus the TIP) to $((...)) is less work than tracking down all the places broken by sticking to $(...).
4.
$((...)) is still nicer and shorter and easier to type than [expr {...}]; the syntax feature will likely reduce bugs.
One doesn't always get exactly what one wants. You've won almost all the arguments (and easily) except for the one about the syntax, where it turns out it's being used in practice for other purposes. In many places. This is where my TCT hat gets involved: I have to consider all that other code as well as your proposal.
What follows will be heated discussion. Syntax discussions have historically always been so.
Donal.
________________________________
From: EricT <tw...@gm...>
Sent: Tuesday, October 21, 2025 13:36
To: Donal Fellows <don...@ma...>
Cc: Brian Griffin <bri...@ea...>; tc...@ro... <tc...@ro...>; Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax
Hi Donal:
Yes, I should have been more careful with that. I see that it is actually $((...)) in bash.
I think the best approach is to find all the uses by both searching and also a pragma that optionally will cause any use of $() to be flagged with an error. Then convert to using one of the two alternative methods.
I understand empty array names exist in production code. It's also important to note that ${()} doesn't work for all cases - it only handles literal indices. When the index involves variable substitution (like $($var)), users must use [set (...)] instead.
The migration path is clear I believe: use [set (...)] which works for all cases, both before and after the feature is enabled.
Thanks again for the feedback.
Eric
On Tue, Oct 21, 2025 at 1:55 AM Donal Fellows <don...@ma...<mailto:don...@ma...>> wrote:
EricT2025-10-21 04:12
1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.
Surely the better shell precedent would be the $((expression)) form? That would also be quite a bit less likely to clash with existing use cases. Hmm, a quick search with https://github.com/search?q=%24%28%28+language%3ATcl&type=code [github.com]<https://urldefense.com/v3/__https://github.com/search?q=*24*28*28*language*3ATcl&type=code__;JSUlKyU!!PDiH4ENfjr2_Jw!Eot1BTBAjUrPeBxEg8km_8tqRFXpHzfHkiNZX7qagLMYARtCjwfj3_uX-YkRBZbGR4sbbT_P-u3u9zqo38ySjFCk4pY$> gives 29 hits (most of which appear to be false positives; the real hits seem to be from one place in JimTcl itself), as opposed to 4k hits when looking for $( in Tcl code; two orders of magnitude less usage. One of the really nice things about a resource like GitHub is that one can quickly search for language syntax features across a lot of code and get a good feeling for practical compatibility.
While $(([llength $x] - 17)) is no shorter than {=}{[llength $x] - 17}, it's definitely easier to type!
(Eric: Don't lose heart! These discussions are a lot less acrimonious than the discussion over what became {*} was.)
Donal.
________________________________
From: EricT <tw...@gm...<mailto:tw...@gm...>>
Sent: Tuesday, October 21, 2025 04:11
To: Brian Griffin <bri...@ea...<mailto:bri...@ea...>>
Cc: tc...@ro...<mailto:tc...@ro...> <tc...@ro...<mailto:tc...@ro...>>; Tcl Core List <tcl...@li...<mailto:tcl...@li...>>
Subject: Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax
Thanks for the feedback, Brian! I understand your concern about the semantic distinction between $ (value) and [ ] (execution).
I'd offer a few thoughts:
1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.
2. $ already involves execution: Even $var involves command execution internally (TclGetVar), it's just optimized. The distinction between "value substitution" and "command execution" is somewhat artificial at the implementation level.
3. expr is special and has historical precedent: Unlike arbitrary commands, expr is used so frequently that syntactic sugar makes sense - similar to how $var is sugar for [set var]. We optimize the common case. I believe there was a time in early Tcl before $var existed when [set var] was the only choice - if so, adding $var as syntactic sugar for variable substitution was a usability win. $(expr) follows the same pattern - sugar for the extremely common [expr {...}] case.
4. Consistency: $(expr) fits the pattern of "$ means substitute something here" - whether a variable, array element, or expression result. Modern languages like Python have embraced similar concepts with f-strings that allow {expression} for inline evaluation. $(expr) brings this convenience to Tcl while maintaining our substitution semantics.
That said, I appreciate the philosophical consistency argument. Do you see the security benefits (auto-bracing) as compelling enough to outweigh the semantic concern?
Did you see the email I sent you about lseq? Maybe it landed in your spam folder - that happened once before as I recall.
Eric
On Mon, Oct 20, 2025 at 7:19 PM Brian Griffin <bri...@ea...<mailto:bri...@ea...>> wrote:
I like the idea of simplifying expression substitutions. The problem I have is that the '$' is defined to be a value substitution. Running a command (execution) is a [] substitution, not a '$' substitution. Conflating the two modes of substitution can cause confusion for newbies, and even experienced programmers.
I recognize that this view is a very subtle distinction, but I think it's important.
Think of it like conflating * vs & in C. (Maybe not that bad, but similar)
-Brian
On Oct 20, 2025, at 07:22, EricT <tw...@gm...<mailto:tw...@gm...>> wrote:
Regarding the discussion in the telco today. If the incompatibility discussed is the known empty array issue, then for that I would propose the following:
There could be a pragma or tcl_dollar_expr global variable with several settings.
1. Work in compatibility mode, i.e. as though the feature was not implemented at all.
2. Work in diagnostic mode, throw an error for any $(...) use
3. Work in full implementation mode
The code to do this, given a global C variable to check would be trivial.
This value could default to 1. for at least 9.1 or 9.2 but there could be an option, similar to tclsh -encoding, that would allow the pragma variable to be set before any init script code is run. This would give developers the opportunity to set the variable to mode 2 in order to easily track down uses of $(index) before any code were to begin using $(expr).
I think it would be quite rare if this syntax change would affect binary extensions, so it should be only with script level coding.
The fix to any code that is using the empty array variable, is to change from,
set val $(index)
set val $($var) - or any other valid index string
to
set val ${(index)}
set val ${($var)}
Likewise for any other use of the $(...) substitution in current use.
This change can begin to be made right away, since it is a compatible syntax that does not change the semantics. Once all the init time script code or packages that use the un-braced syntax are found and changed, the feature could begin to be used by those who are interested.
On the other hand, if the incompatibility is something other than this empty array, I'd be most appreciative to know what it is.
thanks
Eric
On Sun, Oct 19, 2025 at 3:44 AM EricT <tw...@gm...<mailto:tw...@gm...>> wrote:
Harald,
Thank you for your willingness to sponsor!
To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl user who, in retirement, wanted to give something back to the Tcl community. Jim Tcl's successful use of this syntax for years demonstrates that the concept is viable.
Regarding the telco: I attempted to join previously but was unsuccessful with the setup. I won't be able to participate on Monday, but I'm available via email for any questions or clarifications that arise from the discussion.
I don't currently have write access to either the Tcl Fossil repository or the TIP repository, so I'm unable to make changes directly. At nearly 80 years old, I'm not comfortable learning new version control systems on my own. If the TIP moves forward, I'd need guidance and assistance with the Fossil workflow, or perhaps someone from the core team who shares our interest in this TIP could handle the integration based on my GitHub prototype.
I'm currently developing a comprehensive test suite in standard tcltest format, with particular focus on edge cases.
Looking forward to hearing how Monday's discussion goes!
Best regards,
Eric
On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <har...@el...<mailto:har...@el...>> wrote:
Eric,
sponsoring is no problem. The point is to get positive votes.
This requires a positive discussion.
You are the Author of Jim?
Could you participate on the telco on Monday?
Do you have write access to the tcl fossil? We would need the
implementation there.
Thanks for all,
Harald
Am 18.10.2025 um 22:58 schrieb EricT:
> Thank you for the positive feedback and for raising this in Monday's
> telco! I'm encouraged by your support.
>
> Regarding $(a) - you're right that reading an empty array element with a
> variable index is a valid construct. However, this is explicitly
> addressed in the TIP and the repository README. The workarounds are
> straightforward:
>
> ${(a)} # Braced form
> [set (a)] # Command substitution
>
> Both still work. In fact, code using $(varname) could be proactively
> modified to use ${(varname)} to indicate the clear intent of an empty
> array reference, which improves readability. The security, performance,
> and usability benefits of $(...) seemed to justify this trade-off for
> Tcl 9.x where some incompatibilities are expected.
>
> Given your interest in the feature, would you be willing to consider
> sponsoring TIP 672? The implementation is working and minimal (~100
> lines across two files), with the main open question being the preferred
> approach for tracking synthetic strings for cleanup. Your guidance on
> that architectural decision would be particularly valuable.
>
> The prototype repository with full implementation and examples is here:
>
> https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$> <https://
> github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>>
>
> Looking forward to the results of the discussion on Monday! I won't be
> able to join the telco discussion, but I'm available via email for any
> questions or clarifications that arise.
>
>
> On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann
> <har...@el...<mailto:har...@el...> <mailto:har...@el...<mailto:har...@el...>>> wrote:
>
> Am 17.10.2025 um 23:22 schrieb EricT:
> > 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 [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>
> <https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>>
> > <https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$> <https://
> github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>>>
> >
> > 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
> Eric,
> great proposal, thank you !
>
> Perhaps, we may discuss this on Monday in the biweekly telco.
> I am also excited and in favor to this.
> Nevertheless, "$(a)" is to my knowledge a quite common syntax for
> arrays. We have already killed less disruptive proposals (see optional
> "- args") by endless discussions and getting nowhere.
> Hope, this will be fruitful.
>
> In addition, I would like to add the Tk test reform by the other
> Eric to
> the biweekly topics.
> Here is a revised agenda proposal proposal:
>
> Top 1) Release calender (TIP 713)
> - 9.0.3: October (2 weeks left)
> - 9.1a1: November (6 weeks left)
> Top 2) TIP 734 nested mutex (go or not)
> Top 3) TIP 733: accessability (test status)
> Top 4) TIP 732: TCL library path (discussion)
> Top 5) TIP 731: use C enums (no brainer?)
> Top 6) TIP 720: new bytecodes (final, great! Any issues?)
> Top 7) TIP 721: Tcl_AttemptGetString
> Top 8) TIP 715: supported build systems
> Top 9) $($a+$b) syntax for expressions
> Top 10) Tk test reform by Eric (Thanks !)
> Top 11) Tcl depot and awthemes ?
> Top 12) AOB
> Top 13) Next meeting:
> 3rd of November 12:00 UTC.
> Daytime saving time ends 2nd of November in US, 26th of
> October in
> Europe.
> Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?
>
> Take care,
> Harald
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Eot1BTBAjUrPeBxEg8km_8tqRFXpHzfHkiNZX7qagLMYARtCjwfj3_uX-YkRBZbGR4sbbT_P-u3u9zqo38ySlCQMhbQ$>
|
|
From: EricT <tw...@gm...> - 2025-10-21 12:53:18
|
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
>
|
|
From: Zaumseil R. <RZa...@kk...> - 2025-10-21 13:00:15
|
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...<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
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
|
|
From: Jan N. <jan...@gm...> - 2025-10-21 13:28:45
|
Op di 21 okt 2025 om 14:53 schreef EricT:
>
> 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.
I think the best way forward is simply to go for the $(...) syntax, as
proposed now in the TIP. Just make it an opt-in feature in Tcl 9.1, and
deprecate the use of empty-string array variables in $-substitutions
(but keep everything as-is for 'set'). I'll try to implement some
interpreter-bound knob (I think that's better than a global knob)
That opens the way to make this behavior the default in Tcl 10....
Thanks!
Jan Nijtmans
|
|
From: Florent M. <flo...@gm...> - 2025-10-21 17:35:10
|
Jan,
Mathematical expression shorthand has been a long term debate, but
consensus has never emerged on this subject.
But, the fact is that the $(...) syntax is breaking code, but the {=}
syntax is not.
Moreover, the concept of word prefix, to modulate interpretation of
words, is a room for many improvements, in a backward compatible way.
One of this improvement is the multiline or inline comments prefix {#}.
So, why prefer a syntax that is breaking code, when it exits an
alternative syntax that is not breaking any code ?
Is it to make people to go far away from Tcl ?
Le 21/10/2025 à 15:28, Jan Nijtmans a écrit :
> Op di 21 okt 2025 om 14:53 schreef EricT:
>> 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.
> I think the best way forward is simply to go for the $(...) syntax, as
> proposed now in the TIP. Just make it an opt-in feature in Tcl 9.1, and
> deprecate the use of empty-string array variables in $-substitutions
> (but keep everything as-is for 'set'). I'll try to implement some
> interpreter-bound knob (I think that's better than a global knob)
>
> That opens the way to make this behavior the default in Tcl 10....
>
> Thanks!
> Jan Nijtmans
>
>
> _______________________________________________
> 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/
|
|
From: Jan N. <jan...@gm...> - 2025-10-21 13:42:45
|
Op ma 20 okt 2025 om 22:59 schreef EricT:
> There is one other edge case with $(expr): the subst command currently treats it as variable substitution. This means:
> subst -nocommands {$(expr)} # Doesn't work - still substitutessubst -novariables {$(expr)} # Works - suppresses substitution
>
>
Good catch ! How about adding a "subst -noexpr"? It works almost the
same
as "subst -novariables", but whether it substitutes depends on whether '$'
is
followed by '(' or not. That shouldn't be too difficult to implement.
Regards,
Jan Nijtmans
|
|
From: EricT <tw...@gm...> - 2025-10-21 17:40:57
|
Jan:
Thanks for the support and looking at a knob.
This is exactly the approach I was hoping for - an interpreter-bound knob
for opt-in in 9.1, with a path to default in 10. I really appreciate you
taking this on.
I'm working on expanding the test suite with comprehensive edge cases to
ensure the implementation is solid. I'll have an updated subexpr.test file
ready soon that can be dropped into the test directory.
Regarding subst and $(, I'd be interested to hear your thoughts on any
options that might help there.
Eric
On Tue, Oct 21, 2025 at 6:42 AM Jan Nijtmans <jan...@gm...> wrote:
> Op ma 20 okt 2025 om 22:59 schreef EricT:
>
>> There is one other edge case with $(expr): the subst command currently treats it as variable substitution. This means:
>> subst -nocommands {$(expr)} # Doesn't work - still substitutessubst -novariables {$(expr)} # Works - suppresses substitution
>>
>>
> Good catch ! How about adding a "subst -noexpr"? It works almost the
> same
> as "subst -novariables", but whether it substitutes depends on whether '$'
> is
> followed by '(' or not. That shouldn't be too difficult to implement.
>
> Regards,
> Jan Nijtmans
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
|
|
From: EricT <tw...@gm...> - 2025-10-21 17:42:39
|
Rene:
Unless I'm mistaken, the approach by Florent is to treat {=} in the same
way as {*}, at least that's what he said in his last message to me. If that
is how he would approach it, then it would not substitute inside of quoted
strings or barewords.
I may be wrong on this, but he hasn't replied to my question about being
able to do so.
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.
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
>
|
|
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/
|
|
From: da S. P. J <pet...@fl...> - 2025-10-21 18:28:49
|
No, that error is because the spaces in “set foo something{*}{1 + 2 + 3}suffix” were interpreted before “{*}” would even have been considered.
The arguments to set in that case are:
something{*}{1
+
2
+
3}suffix
From: Florent Merlet <flo...@gm...>
Date: Tuesday, October 21, 2025 at 13:24
To: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
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
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=uzKH4hlQZ_k-_YWuVjU4ztQovVeAnil8nvhs2l-GlFd7CkfK4-CHuqb8UmHe46fP&s=lw6bJuHgl9a55KQ0wg5rkmIKIHFEn44L5uMkQhVmq-Y&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=uzKH4hlQZ_k-_YWuVjU4ztQovVeAnil8nvhs2l-GlFd7CkfK4-CHuqb8UmHe46fP&s=r4JuJZ7ly1-tsryKo0BXikrNbc0hmSO4E1WGB_3drRg&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=uzKH4hlQZ_k-_YWuVjU4ztQovVeAnil8nvhs2l-GlFd7CkfK4-CHuqb8UmHe46fP&s=r4JuJZ7ly1-tsryKo0BXikrNbc0hmSO4E1WGB_3drRg&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=uzKH4hlQZ_k-_YWuVjU4ztQovVeAnil8nvhs2l-GlFd7CkfK4-CHuqb8UmHe46fP&s=r4JuJZ7ly1-tsryKo0BXikrNbc0hmSO4E1WGB_3drRg&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
|
|
From: EricT <tw...@gm...> - 2025-10-21 18:37:34
|
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
>
|
|
From: Florent M. <flo...@gm...> - 2025-10-21 19:01:12
|
Why not ? {=} can be check in Tcl_ParseToken.
(bin) 1 % set foo "abc {=}1+2+3 def"
(bin) 2 % set foo something{=}1+2+3
(bin) 3 % string range "abcdef" 1 end-{=}3-2
(bin) 4 % set n 3
(bin) 5 % string range "abcdef" 1 end-{=}$n-2
Le 21/10/2025 à 20:37, EricT a écrit :
> 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 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/
>
> _______________________________________________
> 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/
|
|
From: EricT <tw...@gm...> - 2025-10-21 18:54:30
|
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
>>
>
|
|
From: Florent M. <flo...@gm...> - 2025-10-21 19:04:39
|
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
>>
>> 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/
>
> _______________________________________________
> 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/
|
|
From: da S. P. J <pet...@fl...> - 2025-10-21 19:11:23
|
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...<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
|
|
From: Donald P. <d.g...@co...> - 2025-10-21 19:24:34
|
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
|
|
From: Donald P. <d.g...@co...> - 2025-10-21 20:13:44
|
> 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. ….unless that string of symbols is meaningful in a string like a regexp or some other mini language embedded in the arguments to some built-in or popular extension command. DGP |
Thanks for helping keep SourceForge clean.
X