tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP 672 Implementation Complete - Ready for Sponsorship

[Florent M. <flo...@gm...>]

So, everybody in the core team agree with the implementation of a new
math-Expression substitution as a memlink command into the procedure in
charge of variable name substitution ?

Le mer. 22 oct. 2025, 14:07, EricT <tw...@gm...> a écrit :

> Hi everyone,
>
> I wanted to update you on the status of TIP 672 (expression substitution
> syntax).
>
> The prototype implementation is now complete and available at:
> https://github.com/rocketship88/tcl-tip-672-prototype
>
> The implementation has been parameterized to support both discussed
> approaches with a simple compile-time flag:
> - Mode 1: $(expr) syntax
> - Mode 2: $=(expr) or $^(expr) - configurable character
>
> Key features:
> - Comprehensive test suite (82 tests covering edge cases)
> - Minimal code changes (~100 lines)
> - Clean integration with existing parser
> - Full Tcl test suite passes (only 3 expected differences)
>
> There is one known issue: a minor memory leak in the synthetic command
> strings that will need attention during integration.
>
> At this point, I need a sponsor to upload the code to a TIP branch on
> Fossil so the core team can review and decide whether to adopt the TIP and,
> if so, which syntax to use. I'm available for any collaborative work,
> questions, or modifications needed.
>
> I'm grateful for all the feedback and support from the community. I look
> forward to the next steps in the process.
>
> Best regards,
> Eric
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] CFV Warning - TIP 733

[Kevin W. <kw...@co...>]

Hi Emiliano,

I committed your patch, thank you. Re-running the test suite on X11 
shows a few failures, but none that are related to accessibility, as far 
as I can tell - and no hangs or segfaults.

Regards,

Kevin

On 10/21/25 9:12 PM, Emiliano wrote:
> Hi Kevin
>
> Se comments below
>
>> I do not intend to have the test suite run with a screen reader active -
>> there is too much overhead with accessibility that may cause conflicts
>> and failures with the test suite. In fact, some of my recent commits
>> have been intended to ensure that the accessibility commands do not leak
>> into the test suite when the screen reader is inactive. Is the above
>> hang occurring with, or without, a screen reader?
> The hang occurs without the screen reader active.
>
>> I've added this change because it seems to be make sense, but I am not
>> changing functionality in child interpreters.
> The problem is that TkAccessibility_Init is run on every child interpreter
> that loads Tk, but the TkAccessibilityObject hash table should be initialized
> just once.
>
>> I've added a cleanup handler for the global TkAccessibilityObject for
>> app exit.
> This is desirable, yes. But the cleanup I had in mind is when widgets are
> destroyed; if not cleaned up, the entries will still be there even when
> they are not needed anymore. See attached patch for a simple solution.
>
> Regards.
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] TIP 672 Implementation Complete - Ready for Sponsorship

[Donal F. <don...@ma...>]

Just needs the option to do the $((...)) form (double parenthesis) to cover the likely bases for what we'll be picking between. I'm guessing that once we're closer to having a syntax picked, we'll need some really aggressive attempts to break the parser for all of this. Fun for test writers... ;-)

There will also need to be a bunch of cleaning up on the formal side (e.g., the TIP contains "TBD" for the Specification) before any vote. I don't expect a big problem there; just a "can't vote on this yet because we're still baking it".

Donal.

________________________________
From: EricT <tw...@gm...>
Sent: Wednesday, October 22, 2025 13:06
To: tcl...@li... <Tcl...@li...>
Cc: et...@ro... <et...@ro...>
Subject: [TCLCORE] TIP 672 Implementation Complete - Ready for Sponsorship

ZjQcmQRYFpfptBannerEnd
Hi everyone,

I wanted to update you on the status of TIP 672 (expression substitution syntax).

The prototype implementation is now complete and available at:
https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!FnU_lkuFMqro--EqlOuN1ArpdwtqBw99MRZ08bb9K5wa51ZyF6etbvazzvALIqobsO0M1KKypbJcYLKnPozRdEvqhQM$>

The implementation has been parameterized to support both discussed approaches with a simple compile-time flag:
- Mode 1: $(expr) syntax
- Mode 2: $=(expr) or $^(expr) - configurable character

Key features:
- Comprehensive test suite (82 tests covering edge cases)
- Minimal code changes (~100 lines)
- Clean integration with existing parser
- Full Tcl test suite passes (only 3 expected differences)

There is one known issue: a minor memory leak in the synthetic command strings that will need attention during integration.

At this point, I need a sponsor to upload the code to a TIP branch on Fossil so the core team can review and decide whether to adopt the TIP and, if so, which syntax to use. I'm available for any collaborative work, questions, or modifications needed.

I'm grateful for all the feedback and support from the community. I look forward to the next steps in the process.

Best regards,
Eric

[TCLCORE] TIP 672 Implementation Complete - Ready for Sponsorship

[EricT <tw...@gm...>]

Hi everyone,

I wanted to update you on the status of TIP 672 (expression substitution
syntax).

The prototype implementation is now complete and available at:
https://github.com/rocketship88/tcl-tip-672-prototype

The implementation has been parameterized to support both discussed
approaches with a simple compile-time flag:
- Mode 1: $(expr) syntax
- Mode 2: $=(expr) or $^(expr) - configurable character

Key features:
- Comprehensive test suite (82 tests covering edge cases)
- Minimal code changes (~100 lines)
- Clean integration with existing parser
- Full Tcl test suite passes (only 3 expected differences)

There is one known issue: a minor memory leak in the synthetic command
strings that will need attention during integration.

At this point, I need a sponsor to upload the code to a TIP branch on
Fossil so the core team can review and decide whether to adopt the TIP and,
if so, which syntax to use. I'm available for any collaborative work,
questions, or modifications needed.

I'm grateful for all the feedback and support from the community. I look
forward to the next steps in the process.

Best regards,
Eric

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[Colin M. <col...@ya...>]

Hi All, perhaps it's time to boost my own expr proposal again.

I like the [= <expr>] idea, but simply aliasing "=" to expr doesn't help 
much because you still need to brace the expression to avoid 
double-substitution problems.  Unbraced works ok for the simple examples 
Florent gives, but in general is problematic, e.g.

set x {[exec cat /secret/file >/dev/tty]}    ;# x might be set from user 
input
...
string range "abcdef" 1 end-[= $x-2]      ;# user sees secret file :-(

My own TIP 676 is a proposal to make [= <expression>] usable and safe.  
It has the advantage of not requiring any change to the dodekalogue and 
is fully compatible with existing code.  It also can be used anywhere 
that [] gets expanded including within quoted strings, which is not the 
case for the {=}{expr} proposal.

There are some downsides:
- Operators and operands need to be separated with spaces, i.e. [= $x - 
2]  not  [= $x-2]
- Only numerical and boolean values can be supported, not string values
- Lazy evaluation of && || ?: is not supported
- The implementation is a little more complicated since it can't use the 
existing [expr] parser.  I supplied a Tcl prototype, linked from the 
TIP, actual implementation would require translating this into C.

I worked on this in 2023 but put it aside because everyone was focussed 
on getting 9.0 released, then I moved on to a different project.  I 
think it's worth considering now that [expr] simplification is back in 
the spotlight.

Colin.

On 22/10/2025 09:05, Zaumseil René via Tcl-Core wrote:
>
> +1 on propagating [= …] vs $(..). Using $(..) as command needs 
> additional explanation.
>
> *Von:*Florent Merlet <flo...@gm...>
> *Gesendet:* Mittwoch, 22. Oktober 2025 07:31
> *An:* Donal Fellows <don...@ma...>; 
> tcl...@li...
> *Betreff:* Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - 
> $(expr) Syntax
>
> Donal,
>
> Another level is the C source level, whose clarity of code is 
> important too : New generations will learn Tcl in the future.
>
> On this point of view, does the implementation of the expression 
> shorthand in a procedure whose name is « Tcl_ParseVarname » look so 
> wonderfull ?
>
> There is already a way to compute a expression in a string, it's 
> through the command substitution []
>
> with : interp alias {} "=" {} expr
>
> % string range "abcdef" 1 end-[= 3-2]
>
> But now, is there really a necessity to pollute the "$" substitution 
> procedure as well, to be able to write :
>
> % string range "abcdef" 1 end-$(3-2)
>
> Semantically, « expression substitution » is more like « command 
> substitution » than like « variable substitution ». That's why, Eric, 
> in his change in Tcl_ParseVarname, has to « transmute » the 
> TCL_TOKEN_VARIABLE into a TCL_TOKEN_COMMAND. Now, Tcl_ParseVarname can 
> return either TCL_TOKEN_VAR, TCL_TOKEN_TEXT or TCL_TOKEN_COMMAND.
>
> The logic is not beautifull. Semantically, the good place for any 
> change like this must be in Tcl_ParseToken, and must rely on the 
> concept of « expression substitution » which has to return 
> a TCL_TOKEN_EXPRESSION
>
> The question is : on what char(s) make that detection ?
>
> why not on the equal sign ?
>
> % string range "abcdef" 1 end-{=}3-2
>
> Ok, its bracketment is not very readable.
>
> For this bracketment, it remains unicode chars
>
> % string range "abcdef" 1 end-⟦3-2⟧
>
> With its ascii variant :
>
> % string range "abcdef" 1 end-[|3-2|]
>
> Florent
>
> Le 21/10/2025 à 23:18, Donal Fellows a écrit :
>
>     We /can/ match all sorts of things. What matters is what we
>     /should/ match. What is in play is how much of a syntactic
>     incompatibility we are willing to stomach. If we decide that we
>     are rejecting /any/ syntax changes that could possibly have a
>     compatibility impact, we have /only/ the option to /reject/ /all/
>     change.
>
>     The key thing that we are looking for here is to be a syntactic
>     alternative for *[expr {expression...}]*, which has many potential
>     uses. The option with {=} has the disadvantage of not being
>     naturally bracketed unless written as *{=}{expression...}* and
>     that's just not the nicest thing (for {*}, we were dealing with
>     reinterpretation of words, with the freedom and restrictions that
>     implies, but that's not in play here), and gets ugly when used in
>     the interior of a word. The options with *$(expression...)* and
>     *$((expression...))* are /much/ less of a problem in that
>     regard... but have more potential for compatibility problems.
>     (These are non-theoretical issues for the *$(expression...)* form,
>     which is /definitely/ in use in the wild; we have found many
>     examples, even if we've not yet worked out if they're truly a
>     problem in all cases.)
>
>     Exactly which code should be adapted once we decide what the
>     language change should be... is just a simple matter of changing
>     what needs changing. In terms of commands affected, I can predict
>     this will have an impact inside *subst* primarily, and possibly
>     *assemble*; I see no need to add it to the expression language.
>
>     Note of course that expressions are expected to syntactically have
>     balanced parentheses (except for comments).
>
>     Donal.
>
>     -------- Original message --------
>
>     From: Florent Merlet <flo...@gm...>
>     <mailto:flo...@gm...>
>
>     Date: 21/10/2025 20:01 (GMT+00:00)
>
>     To: tc...@ro...
>
>     Cc: tcl...@li...
>
>     Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 -
>     $(expr) Syntax
>
>     Why not ? {=} can be check in Tcl_ParseToken.
>
> -- 
>
> ------------------------------------------------------------------------
>
> *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

Re: [TCLCORE] TCLTLS and SNI for multiple HTTPS target hosts

[Alexander S. <a.s...@gm...>]

Hi Harald,

thank you for the info. I’m aware of the -autoservername option introduced in TclTLS 1.7.1, but I suspect it may not fully solve the issue in my case, especially when using multiple HTTPS hosts within the same script.

From what I can tell, TclTLS 2 introduces some changes to how these options behave, and the handling seems to differ compared to 1.x versions. I’ve been reviewing the updated documentation here:
    • https://chiselapp.com/user/bohagan/repository/TCLTLS/file?name=doc/tls.html&ci=tip
    • https://chiselapp.com/user/bohagan/repository/TCLTLS/wiki?name=TCLTLS+Redux

It appears that -servername now defaults to the socket host, and -autoservername defaults to true if not explicitly set – which should help in most cases. However, I’m still unsure how to handle dynamic connections to different servers if the TLS context needs to be unique per request.

I saw that Brian posted a detailed message about TclTLS 2 on the newsgroup. That might cover exactly what I’m running into.
If possible, I’d appreciate it if you could forward his message to the Tcl core mailing list – or perhaps Brian could directly comment on this?

Best,
Alex

> Am 22.10.2025 um 08:33 schrieb Harald Oehlmann <har...@el...>:
> 
> Alex,
> TCLTLS 1.7.1 introduced "-autoservername" option.
> Does this solve your issue?
> Harald
> 
> Am 22.10.2025 um 08:26 schrieb Alexander Schöpe via Tcl-Core:
>> Hi Brian,
>> I have a question regarding the use of tcltls in combination with the http package, specifically concerning Server Name Indication (SNI).
>> Recently, it seems that some Apache web servers have changed their configuration, and I’m increasingly encountering the 421 Misdirected Request error when making HTTPS requests without explicitly setting the servername field during the TLS handshake.
>> The error message is typically something like:
>> The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.
>> I’ve been able to work around this issue for a single target server by explicitly registering HTTPS like this:
>> http::register https 443 [list ::tls::socket -tls1 1 -servername bla.example.com]
>> However, my question is:
>> What is the recommended approach if I need to contact multiple different HTTPS servers within the same Tcl script?
>> Since http::register is global for the https scheme, it doesn’t seem possible to dynamically assign the -servername per connection.
>> Is there a best practice or suggested workaround – perhaps by creating a custom socket for each http::geturl call with the correct SNI set depending on the target host?
>> Any advice would be much appreciated.
>> Best
>> Alex
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[Zaumseil R. <RZa...@kk...>]

+1 on propagating [= …] vs $(..). Using $(..) as command needs additional explanation.

Von: Florent Merlet <flo...@gm...>
Gesendet: Mittwoch, 22. Oktober 2025 07:31
An: Donal Fellows <don...@ma...>; tcl...@li...
Betreff: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax


Donal,

Another level is the C source level, whose clarity of code is important too : New generations will learn Tcl in the future.

On this point of view, does the implementation of the expression shorthand in a procedure whose name is « Tcl_ParseVarname » look so wonderfull ?

There is already a way to compute a expression in a string, it's through the command substitution []

with : interp alias {} "=" {} expr

% string range "abcdef" 1 end-[= 3-2]

But now, is there really a necessity to pollute the "$" substitution procedure as well, to be able to write :

% string range "abcdef" 1 end-$(3-2)

Semantically, « expression substitution » is more like « command substitution » than like « variable substitution ». That's why, Eric, in his change in Tcl_ParseVarname, has to « transmute » the TCL_TOKEN_VARIABLE into a TCL_TOKEN_COMMAND. Now, Tcl_ParseVarname can return either TCL_TOKEN_VAR, TCL_TOKEN_TEXT or TCL_TOKEN_COMMAND.

The logic is not beautifull. Semantically, the good place for any change like this must be in Tcl_ParseToken, and must rely on the concept of « expression substitution » which has to return a TCL_TOKEN_EXPRESSION

The question is : on what char(s) make that detection ?

why not on the equal sign ?

% string range "abcdef" 1 end-{=}3-2

Ok, its bracketment is not very readable.

For this bracketment, it remains unicode chars

% string range "abcdef" 1 end-⟦3-2⟧

With its ascii variant :

% string range "abcdef" 1 end-[|3-2|]



Florent
Le 21/10/2025 à 23:18, Donal Fellows a écrit :
We can match all sorts of things. What matters is what we should match. What is in play is how much of a syntactic incompatibility we are willing to stomach. If we decide that we are rejecting any syntax changes that could possibly have a compatibility impact, we have only the option to reject all change.

The key thing that we are looking for here is to be a syntactic alternative for [expr {expression...}], which has many potential uses. The option with {=} has the disadvantage of not being naturally bracketed unless written as {=}{expression...} and that's just not the nicest thing (for {*}, we were dealing with reinterpretation of words, with the freedom and restrictions that implies, but that's not in play here), and gets ugly when used in the interior of a word. The options with $(expression...) and $((expression...)) are much less of a problem in that regard... but have more potential for compatibility problems. (These are non-theoretical issues for the $(expression...) form, which is definitely in use in the wild; we have found many examples, even if we've not yet worked out if they're truly a problem in all cases.)

Exactly which code should be adapted once we decide what the language change should be... is just a simple matter of changing what needs changing. In terms of commands affected, I can predict this will have an impact inside subst primarily, and possibly assemble; I see no need to add it to the expression language.

Note of course that expressions are expected to syntactically have balanced parentheses (except for comments).

Donal.

-------- Original message --------
From: Florent Merlet <flo...@gm...><mailto:flo...@gm...>
Date: 21/10/2025 20:01 (GMT+00:00)
To: tc...@ro...<mailto:tc...@ro...>
Cc: tcl...@li...<mailto:tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

Why not ? {=} can be check in Tcl_ParseToken.
--
________________________________
Florent MERLET
4 rue Johann Strauss
Logement 7
86180 BUXEROLLES
________________________________
Mél. : flo...@gm...<mailto:flo...@gm...>
Tél. : 06 70 00 63 48

Re: [TCLCORE] TCLTLS and SNI for multiple HTTPS target hosts

[Harald O. <har...@el...>]

Alex,
TCLTLS 1.7.1 introduced "-autoservername" option.
Does this solve your issue?
Harald

Am 22.10.2025 um 08:26 schrieb Alexander Schöpe via Tcl-Core:
> Hi Brian,
> 
> I have a question regarding the use of tcltls in combination with the http package, specifically concerning Server Name Indication (SNI).
> 
> Recently, it seems that some Apache web servers have changed their configuration, and I’m increasingly encountering the 421 Misdirected Request error when making HTTPS requests without explicitly setting the servername field during the TLS handshake.
> 
> The error message is typically something like:
> 
> The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.
> 
> I’ve been able to work around this issue for a single target server by explicitly registering HTTPS like this:
> 
> http::register https 443 [list ::tls::socket -tls1 1 -servername bla.example.com]
> 
> However, my question is:
> What is the recommended approach if I need to contact multiple different HTTPS servers within the same Tcl script?
> Since http::register is global for the https scheme, it doesn’t seem possible to dynamically assign the -servername per connection.
> 
> Is there a best practice or suggested workaround – perhaps by creating a custom socket for each http::geturl call with the correct SNI set depending on the target host?
> 
> Any advice would be much appreciated.
> 
> Best
> Alex

[TCLCORE] TCLTLS and SNI for multiple HTTPS target hosts

[Alexander S. <a.s...@gm...>]

Hi Brian,

I have a question regarding the use of tcltls in combination with the http package, specifically concerning Server Name Indication (SNI).

Recently, it seems that some Apache web servers have changed their configuration, and I’m increasingly encountering the 421 Misdirected Request error when making HTTPS requests without explicitly setting the servername field during the TLS handshake.

The error message is typically something like:

The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.

I’ve been able to work around this issue for a single target server by explicitly registering HTTPS like this:

http::register https 443 [list ::tls::socket -tls1 1 -servername bla.example.com]

However, my question is:
What is the recommended approach if I need to contact multiple different HTTPS servers within the same Tcl script?
Since http::register is global for the https scheme, it doesn’t seem possible to dynamically assign the -servername per connection.

Is there a best practice or suggested workaround – perhaps by creating a custom socket for each http::geturl call with the correct SNI set depending on the target host?

Any advice would be much appreciated.

Best
Alex

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[Florent M. <flo...@gm...>]

Donal,

Another level is the C source level, whose clarity of code is important 
too : New generations will learn Tcl in the future.

On this point of view, does the implementation of the expression 
shorthand in a procedure whose name is « Tcl_ParseVarname » look so 
wonderfull ?

There is already a way to compute a expression in a string, it's through 
the command substitution []

with : interp alias {} "=" {} expr

% string range "abcdef" 1 end-[= 3-2]

But now, is there really a necessity to pollute the "$" substitution 
procedure as well, to be able to write :

% string range "abcdef" 1 end-$(3-2)

Semantically, « expression substitution » is more like « command 
substitution » than like « variable substitution ». That's why, Eric, in 
his change in Tcl_ParseVarname, has to « transmute » the 
TCL_TOKEN_VARIABLE into a TCL_TOKEN_COMMAND. Now, Tcl_ParseVarname can 
return either TCL_TOKEN_VAR, TCL_TOKEN_TEXT or TCL_TOKEN_COMMAND.

The logic is not beautifull. Semantically, the good place for any change 
like this must be in Tcl_ParseToken, and must rely on the concept of « 
expression substitution » which has to return a TCL_TOKEN_EXPRESSION

The question is : on what char(s) make that detection ?

why not on the equal sign ?

% string range "abcdef" 1 end-{=}3-2

Ok, its bracketment is not very readable.

For this bracketment, it remains unicode chars

% string range "abcdef" 1 end-⟦3-2⟧

With its ascii variant :

% string range "abcdef" 1 end-[|3-2|]


Florent

Le 21/10/2025 à 23:18, Donal Fellows a écrit :
> We /can/ match all sorts of things. What matters is what we /should/ 
> match. What is in play is how much of a syntactic incompatibility we 
> are willing to stomach. If we decide that we are rejecting /any/ 
> syntax changes that could possibly have a compatibility impact, we 
> have /only/ the option to /reject/ /all/ change.
>
> The key thing that we are looking for here is to be a syntactic 
> alternative for *[expr {expression...}]*, which has many potential 
> uses. The option with {=} has the disadvantage of not being naturally 
> bracketed unless written as *{=}{expression...}* and that's just not 
> the nicest thing (for {*}, we were dealing with reinterpretation of 
> words, with the freedom and restrictions that implies, but that's not 
> in play here), and gets ugly when used in the interior of a word. The 
> options with *$(expression...)* and *$((expression...))* are /much/ 
> less of a problem in that regard... but have more potential for 
> compatibility problems. (These are non-theoretical issues for the 
> *$(expression...)* form, which is /definitely/ in use in the wild; we 
> have found many examples, even if we've not yet worked out if they're 
> truly a problem in all cases.)
>
> Exactly which code should be adapted once we decide what the language 
> change should be... is just a simple matter of changing what needs 
> changing. In terms of commands affected, I can predict this will have 
> an impact inside *subst* primarily, and possibly *assemble*; I see no 
> need to add it to the expression language.
>
> Note of course that expressions are expected to syntactically have 
> balanced parentheses (except for comments).
>
> Donal.
>
> -------- Original message --------
> From: Florent Merlet <flo...@gm...>
> Date: 21/10/2025 20:01 (GMT+00:00)
> To: tc...@ro...
> Cc: tcl...@li...
> Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - 
> $(expr) Syntax
>
> Why not ? {=} can be check in Tcl_ParseToken.
>
-- 
------------------------------------------------------------------------
*Florent MERLET*
/4 rue Johann Strauss
Logement 7
86180 BUXEROLLES/
------------------------------------------------------------------------
*Mél.* : /flo...@gm.../
*Tél.* : /06 70 00 63 48/

Re: [TCLCORE] CFV Warning - TIP 733

[Emiliano <emi...@gm...>]

Hi Kevin

Se comments below

> I do not intend to have the test suite run with a screen reader active - 
> there is too much overhead with accessibility that may cause conflicts 
> and failures with the test suite. In fact, some of my recent commits 
> have been intended to ensure that the accessibility commands do not leak 
> into the test suite when the screen reader is inactive. Is the above 
> hang occurring with, or without, a screen reader?

The hang occurs without the screen reader active.

> I've added this change because it seems to be make sense, but I am not 
> changing functionality in child interpreters.

The problem is that TkAccessibility_Init is run on every child interpreter
that loads Tk, but the TkAccessibilityObject hash table should be initialized
just once.

> I've added a cleanup handler for the global TkAccessibilityObject for 
> app exit.

This is desirable, yes. But the cleanup I had in mind is when widgets are
destroyed; if not cleaned up, the entries will still be there even when
they are not needed anymore. See attached patch for a simple solution.

Regards.

-- 
Emiliano

Re: [TCLCORE] CFV Warning - TIP 733

[Kevin W. <kw...@co...>]

Hi Emiliano,

Thanks for your input. Please see my responses below:

On 10/21/25 2:52 PM, Emiliano wrote:
> On Sat, 18 Oct 2025 17:07:03 -0400
> Kevin Walzer <kw...@co...> wrote:
>
> Hi Kevin
>
> This is an amazing work, providing a long awaited feature. Thanks !!
I appreciate your good words.
>
> I started testing tka11y branch on X11 (linux, x86_64). So far, I've been able
> to find these issues
>
> * The following line in the configure script is not required to build with
>    atk support. Gtk is not needed.
>
>       && pkg-config --exists gtk+-3.0 \
I've removed this.
>
> * Starting wish shows a short but visible delay in which the default
>    root window is mapped on screen (200x200). This is most noticeable
>    starting applications such as tkcon, in which the root window is
>    displayed and then withdrawn.
>    This delay is in Tk initialization, not process initialization;
>    loading Tk in a child interpreter shows the same delay.
There is a fair amount of initialization going on with accessibility on 
Wish startup, so this slight delay is probably unavoidable. In any event 
I do not see it as a serious issue.
>
> * Test textWind-17.10 (peer widget window configuration test) hangs, and
>    closing the tktest window afterwards segfaults.
>    I was unable to isolate this hang completely. Simply running the text
>    tests with TESTFLAGS="-file text*" doesn't hang, so it must depend on
>    something that runs earlier in the test suite.
>    Also, can't say anything about any further tests in the test suite.
I do not intend to have the test suite run with a screen reader active - 
there is too much overhead with accessibility that may cause conflicts 
and failures with the test suite. In fact, some of my recent commits 
have been intended to ensure that the accessibility commands do not leak 
into the test suite when the screen reader is inactive. Is the above 
hang occurring with, or without, a screen reader?
>
> * Widgets must be mapped before using [tk accessible get_acc_*]
>    with them. Example
>
>    # ---- unmapped.tcl
>    pack [entry .e]
>    tk accessible add_acc_object .e
>    puts [tk accessible get_acc_role .e]
>    # ----
>    $ ./wish9.1  unmapped.tcl
>    No table found. You must set the accessibility role first.
>
>    # ---- mapped.tcl
>    pack [entry .e]
>    tk accessible add_acc_object .e
>    update
>    puts [tk accessible get_acc_role .e]
>    # ----
>    $ ./wish9.1 mapped.tcl
>    Entry
Yes, this is the intended design. The accessibility bindings are bound 
to <Map> events - it's the only way I've found to get them initialized 
in a clean manner.
>
> * The data in commands [tk accessible {get|set}_acc_*] is not multi
>    interp safe. Running the folowing code
>
>    # ---- childinterp.tcl
>    pack [entry .e]
>    tk accessible add_acc_object .e
>    update
>    after 2000 {
>      puts "before: [tk accessible get_acc_role .e]"
>      # create a new Tk application and then delete it
>      interp create i
>      i eval {package require Tk}
>      interp delete i
>      # we can no longer access the accessibility data tables
>      catch {tk accessible get_acc_role .e} err od
>      puts "after: $err\n$od"
>      exit
>    }
>    # ----
>
>    results in (return options dictionary formatted)
>
>    $ ./wish9.1 childinterp.tcl
>    before: Entry
>    after: No table found. You must set the accessibility role first.
>    -code 1 -level 0 -errorstack {INNER {invokeStk tk accessible get_acc_role .e}}
>    -errorcode NONE -errorinfo {No table found. You must set the accessibility role first.
>        while executing
>    "tk accessible get_acc_role .e"} -errorline 1
To avoid test suite failures, accessibility does not load in child 
interpreters. I am documenting this in the man page.
>
>    The solution here is simple: declare and initialize TkAccessibilityObject
>    as NULL
>
>    Tcl_HashTable *TkAccessibilityObject = NULL;
>
>    and only allocate and initialize as hash table if NULL in the
>    TkAccessibility_Init function
>
>    if (!TkAccessibilityObject) {
>      TkAccessibilityObject = (Tcl_HashTable *)ckalloc(sizeof(Tcl_HashTable));
>      Tcl_InitHashTable(TkAccessibilityObject, TCL_ONE_WORD_KEYS);
>    }
I've added this change because it seems to be make sense, but I am not 
changing functionality in child interpreters.
>
> * When widgets are destroyed, the hash tables are not cleaned up, at least
>    the TkAccessibilityObject hash table from generic/tkAccessibility.c .
>    Even recreating a widget with the same pathname and class will,
>    most likely, result in a different tkwin pointer, resulting in an ever
>    growing table with lots of unused entries.
>    Can't say anything about the GLib based hash tables as I don't know how
>    they work.
>    I see there's an event handler for widget deletion in
>    unix/tkUnixAccessibility.c , but there's no cleanup on the above mentioned
>    hash table there. I guess the same applies to both Win and Mac specific
>    code.

I've added a cleanup handler for the global TkAccessibilityObject for 
app exit.

Thanks,

Kevin

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[EricT <tw...@gm...>]

Donald:
Donal:

Thanks for the feedback! I appreciate both perspectives on this.

Both approaches have merit. $= avoids compatibility issues entirely, while
$(...) is more intuitive and has shell precedent. I've implemented both -
happy to go with whatever the core team decides.

Donald's suggestion of using a non-conflicting character would allow the
feature to go directly into 9.x without any compatibility concerns or
pragma mechanism. On the other hand, Donal's preference for $(...)
maintains the cleaner syntax with shell familiarity, and the pragma
approach provides a reasonable migration path for the empty array edge case.

If it would be helpful, I could set up the implementation with compile-time
options to support both mechanisms simultaneously, making it easy to test
and compare both approaches.

Either way, I'm ready to move forward with whichever direction the team
feels is best for Tcl.


Eric


On Tue, Oct 21, 2025 at 2:18 PM Donal Fellows <
don...@ma...> wrote:

> We *can* match all sorts of things. What matters is what we * should*
> match. What is in play is how much of a syntactic incompatibility we are
> willing to stomach. If we decide that we are rejecting *any* syntax
> changes that could possibly have a compatibility impact, we have *only*
> the option to *reject* *all* change.
>
> The key thing that we are looking for here is to be a syntactic
> alternative for *[expr {expression...}]*, which has many potential uses.
> The option with {=} has the disadvantage of not being naturally bracketed
> unless written as *{=}{expression...}* and that's just not the nicest
> thing (for {*}, we were dealing with reinterpretation of words, with the
> freedom and restrictions that implies, but that's not in play here), and
> gets ugly when used in the interior of a word. The options with
> *$(expression...)* and *$((expression...))* are *much* less of a problem
> in that regard... but have more potential for compatibility problems.
> (These are non-theoretical issues for the *$(expression...)* form, which
> is *definitely* in use in the wild; we have found many examples, even if
> we've not yet worked out if they're truly a problem in all cases.)
>
> Exactly which code should be adapted once we decide what the language
> change should be... is just a simple matter of changing what needs
> changing. In terms of commands affected, I can predict this will have an
> impact inside *subst* primarily, and possibly *assemble*; I see no need
> to add it to the expression language.
>
> Note of course that expressions are expected to syntactically have
> balanced parentheses (except for comments).
>
> Donal.
>
> -------- Original message --------
> From: Florent Merlet <flo...@gm...>
> Date: 21/10/2025 20:01 (GMT+00:00)
> To: tc...@ro...
> Cc: tcl...@li...
> Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr)
> Syntax
>
> Why not ? {=} can be check in Tcl_ParseToken.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[Donal F. <don...@ma...>]

We can match all sorts of things. What matters is what we should match. What is in play is how much of a syntactic incompatibility we are willing to stomach. If we decide that we are rejecting any syntax changes that could possibly have a compatibility impact, we have only the option to reject all change.

The key thing that we are looking for here is to be a syntactic alternative for [expr {expression...}], which has many potential uses. The option with {=} has the disadvantage of not being naturally bracketed unless written as {=}{expression...} and that's just not the nicest thing (for {*}, we were dealing with reinterpretation of words, with the freedom and restrictions that implies, but that's not in play here), and gets ugly when used in the interior of a word. The options with $(expression...) and $((expression...)) are much less of a problem in that regard... but have more potential for compatibility problems. (These are non-theoretical issues for the $(expression...) form, which is definitely in use in the wild; we have found many examples, even if we've not yet worked out if they're truly a problem in all cases.)

Exactly which code should be adapted once we decide what the language change should be... is just a simple matter of changing what needs changing. In terms of commands affected, I can predict this will have an impact inside subst primarily, and possibly assemble; I see no need to add it to the expression language.

Note of course that expressions are expected to syntactically have balanced parentheses (except for comments).

Donal.

-------- Original message --------
From: Florent Merlet <flo...@gm...>
Date: 21/10/2025 20:01 (GMT+00:00)
To: tc...@ro...
Cc: tcl...@li...
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

Why not ? {=} can be check in Tcl_ParseToken.

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[Florent M. <flo...@gm...>]

It's true

in tcl ParseVarName :

3. The $ sign is followed by something that isn't a letter, digit, or
      *      underscore: in this case, there is no variable name and the 
token is
      *      just "$".

There is many possibilities finaly

for instance

% set x $/1+2

% set x $!1+2

are possible as well

Florent


Le 21/10/2025 à 21:24, Donald Porter a écrit :
> The {*} syntax introduced in Tcl 8.5 was a syntax for revising the determination of word boundaries.  It needed to be connected to words.
>
> That is not what the current discussion seeks.
> The current discussion seeks to introduce syntax for a new form of substitution.
>
> The particular proposal for syntax $(…) suffers from the problem that it is already a working substitution syntax for the substitution of an element in an array variable with the empty name.
>
> Without thinking deeply and exhaustively about it, let me toss out the option of
>
> 	$=(…)
>
> This syntax does not currently perform a substitution.  It is just literal text.  Promoting it to a substitution syntax should be less disruptive.
>
> DGP
>
>
>
-- 
------------------------------------------------------------------------
*Florent MERLET*
/4 rue Johann Strauss
Logement 7
86180 BUXEROLLES/
------------------------------------------------------------------------
*Mél.* : /flo...@gm.../
*Tél.* : /06 70 00 63 48/

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[da S. P. J <pet...@fl...>]

> if {=} is a valid string, does it mean it has ever been used in the code base ?

Wrong question.

The question is, is any string containing “{=}” going to be passed to subst in anyone’s code anywhere in the world. It was safe to use “{*}” at the beginning of a token because that was not legal Tcl. No working code could contain that string, and it was only exposed in the context of actual auditable code.

From: Florent Merlet <flo...@gm...>
Date: Tuesday, October 21, 2025 at 14:57
To: da Silva, Peter J (USA) <pet...@fl...>, tc...@ro... <tc...@ro...>
Cc: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
if {=} is a valid string, does it mean it has ever been used in the code base ? in tcl repro : https: //github. com/search?q=repo%3Atcltk%2Ftcl%20%7B%3D%7D&type=code one occurence in tools/regexpTestLib. tcl => if {[regexp {=} $flags] ==


if {=} is a valid string, does it mean it has ever been used in the code base ?

in tcl repro : https://github.com/search?q=repo%3Atcltk%2Ftcl%20%7B%3D%7D&type=code<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftcl-2520-257B-253D-257D-26type-3Dcode&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=CyfsegsVMbQTM8BUOM3QAFgUyMu6A2qql4-wcgXkTWU&e=>

 one occurence in tools/regexpTestLib.tcl<https://urldefense.us/v2/url?u=https-3A__github.com_tcltk_tcl_blob_a9f6ab7dba8851da58fec404aa3fa4679bac0e93_tools_regexpTestLib.tcl-23L198&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=f_l9v0uAjxDkCoCD983cJCGF1mO5AEgDEvVHYj8xrU0&e=>

=> if {[regexp {=} $flags] == 1} # (false positive)

in tk repro : https://github.com/search?q=repo%3Atcltk%2Ftk%20%7B%3D%7D&type=code<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftk-2520-257B-253D-257D-26type-3Dcode&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=9Me6yTEagX62EN9QV2Qqu-oAyS4V4bOeKRMORRz5fqg&e=>

no occurence

in tcllib repro : https://github.com/search?q=repo%3Atcltk%2Ftcllib%20<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftcllib-2520&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=24_EwvyMubvwYtieY_qXCr60SaMCmKc0ZzDnc3oFAG0&e=>{%3D}&type=code

no occurence

in tklib repro : https://github.com/search?q=repo%3Atcltk%2Ftklib%20<https://urldefense.us/v2/url?u=https-3A__github.com_search-3Fq-3Drepo-253Atcltk-252Ftklib-2520&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=SmmSS3UDkE4AqNilKebp_YQ_6I_yIeWoUjlgsfKwVAyhiyCtZlnU5yle1JaYj0oo&s=NfS1Gl9HPof5QLWw5x6P7PK7dpYz48q3bPWrzfg2XuY&e=>{%3D}&type=code

no occurence.

I don't see any breakage there.
Le 21/10/2025 à 21:11, da Silva, Peter J a écrit :
If “{=}” is detected inside tokens this will cause all kinds of breakage that is going to be a lot harder to keep track of than “$(...)”, because right now “{=}” is a valid string in Tcl.

The {*} special case at the beginning of an argument was safe because no valid Tcl code could have {*}... as an element of a list.

From: Florent Merlet <flo...@gm...><mailto:flo...@gm...>
Date: Tuesday, October 21, 2025 at 14:05
To: tc...@ro...<mailto:tc...@ro...> <tc...@ro...><mailto:tc...@ro...>
Cc: tcl...@li...<mailto:tcl...@li...> <tcl...@li...><mailto:tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
Yes you are right, I was wrong, {*} is not implemented into Tcl_ParseToken. There is no need for it. But it can't be the same for an {=} prefix : it should be detected inside tokens. Florent Le 21/10/2025 à 20: 54, EricT a écrit : I don't think

Yes you are right, I was wrong,  {*} is not implemented into Tcl_ParseToken.

There is no need for it.

But it can't be the same for an {=} prefix : it should be detected inside tokens.

Florent


Le 21/10/2025 à 20:54, EricT a écrit :
I don't think you are correct about {*} in a bareword that's not in quotes:

% proc foo args {puts /$args/}
% foo something{*}{1 + 2 + 3}suffix
/something\{*\}\{1 + 2 + 3\}suffix/
% foo something{*}{1+2+3}suffix
/something{*}{1+2+3}suffix/
% foo {*}{1 2 3}
/1 2 3/
% foo {*}"1 2 3"
/1 2 3/
% foo {*}"123"
/123/
In either of the first 2 cases, it is inserting the {*}{...} as simply text, it is not removing the {*} nor the enclosing {...} and then expanding it to a list. However, it does do all those steps in the 3rd - 5th cases because {*} begins the word.

Eric


On Tue, Oct 21, 2025 at 11:37 AM EricT <tw...@gm...<mailto:tw...@gm...>> wrote:
Ok, so from what I can tell, you are saying that your {=} will not substitute if inside of "quotes {=}..." or barewords.

Here's $(expr) today:

(bin) 1 % set foo "abc $(1 + 2 + 3) def"
abc 6 def
(bin) 2 % set foo something$(1 + 2 + 3)
something6
(bin) 3 % string range "abcdef" 1 end-$(3-2)
bcde
(bin) 4 % set n 3
3
(bin) 5 % string range "abcdef" 1 end-$($n-2)
bcde
Can your proposed {=} do this, because [expr] can do it too. And therefore so can $(expr).

Eric


On Tue, Oct 21, 2025 at 11:24 AM Florent Merlet <flo...@gm...<mailto:flo...@gm...>> wrote:
Le 21/10/2025 à 19:16, EricT a écrit :
The code that handles {*} is somewhat simple because it begins at a word boundary only:

% set foo "abc {*}{1 +2 +3}"
abc {*}{1 +2 +3}
% set foo something{*}{1 + 2 + 3}suffix
wrong # args: should be "set varName ?newValue?"

That means that if his {=} code is implemented the same as {*} the above is what you will get.

Your coding experiment shows precisely that {*} doesn't work only at a word boundary.

if {*} were not detected, « set » would not have complained : it would have silently set foo as "something{*}{1 + 2 + 3}suffix"

But, as  {*} has been detected, it then evaluates  something like :

% set foo something1 2 3suffix  # (? to be checked ?)

This gives at least 4 arguments to « set », so you got this error.

That means that if his {=} code is implemented the same as {*}, the interpreter would have computed the expression 1+2+3 and returned the number 6, so that the variable foo would have been set to « something6suffix ».

{*} is ignored only between quotes. This is'nt an error :

% set foo "something{*}{1 + 2 + 3}suffix"

-> something{*}{1 + 2 + 3}suffix

On the other hand, $(expr) works everywhere $var works. That is why it can be implemented in ~100 lines of code.

But again, I may be wrong, I was hoping to hear from  Florent on this.

Eric


On Tue, Oct 21, 2025 at 6:00 AM Zaumseil René via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:
Hello Eric

A solution to the second point is also in the mail from Florent Merlot with extending {=}

The third point is about a radical change with removing the $-sign to access variables, p.e. x=y+a. This is way out of current proposals.


Regards
rene

Von: EricT <tw...@gm...<mailto:tw...@gm...>>
Gesendet: Dienstag, 21. Oktober 2025 14:53
An: Zaumseil René <RZa...@kk...<mailto:RZa...@kk...>>
Cc: tc...@ro...<mailto:tc...@ro...>; tcl...@li...<mailto:tcl...@li...>; et...@ro...<mailto:et...@ro...>
Betreff: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

The main reason for the $(...) syntax is to encourage the use of safer, compiled, expression code. Since it would also be easier to read and write, users would gravitate to its use and automatically get the benefit of braced expr code.

The secondary reason is that many have complained about [expr {}] being, not as clean syntax as they would like for expression handling. So, like $var instead of [set var] a $(...) shorthand for [expr {...}].

I looked at TIP 647, is that the one you really meant, I saw only a discussion on  Tk_ConfigureWidgets().

Can you elaborate on your 3rd point? I don't quite understand.

Eric


On Tue, Oct 21, 2025 at 1:36 AM Zaumseil René via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:
Hello

I currently do not see the benefit of this proposal, except some char less to type.
IMHO expr has some problems or room for enhancements:

  1.  Double evaluation of arguments

Could be solved with a new command with only 1 argument

  1.  Returns only one value

See p.e. tip 647 syntax

  1.  Access to tcl-variables with $-syntax

This would require a new expression parser

  1.  Anything else?

Do the tip 672 solve one of these points?


Regards
rene

Von: EricT <tw...@gm...<mailto:tw...@gm...>>
Gesendet: Freitag, 17. Oktober 2025 23:22
An: tcl...@li...<mailto:tcl...@li...>
Cc: et...@ro...<mailto:et...@ro...>
Betreff: [Ext] [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax

Hello Tcl Core Team,

I have developed a working prototype implementation of TIP 672, which adds the $(expression) syntax as a more intuitive alternative to [expr {expression}].

Repository: https://github.com/rocketship88/tcl-tip-672-prototype<https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=kOgnKtNg5S0p_z-nZS7HAnBrb0GrBKOlYvbsUmtlt7w&e=>

The implementation is minimal, modifying only two files (tclParse.c and tclNamesp.c) with approximately 100 lines of changes. The key modification converts the existing two-way branch in Tcl_ParseVarName to a three-way branch, with the new path handling $(...) by creating a synthetic [expr {...}] command string.

Key Accomplishments:

Full bytecode compilation: The synthetic string approach integrates seamlessly with the existing compiler, producing identical optimized bytecode as [expr {...}]. The disassembler output (shown in the README) demonstrates efficient variable loading with no runtime parsing overhead.

Proven approach: Jim Tcl has used this syntax successfully for years

Comprehensive testing: Works correctly with string interpolation, variable scoping, error handling, and interactive mode

Known Limitations:

Memory leak: The synthetic string is allocated but not tracked for cleanup in Tcl_FreeParse. This requires core team guidance on the preferred solution (modify Tcl_Parse structure vs. thread-local tracking).

Error messages: Currently show the synthetic command rather than the original $(...) syntax, though this is arguably helpful for debugging.

Questions for the Team:

What is the preferred approach for tracking synthetic strings for cleanup?
Is this prototype architecture acceptable for Tcl 9.x?
Are there concerns with the synthetic string approach that I should address?

The complete implementation with side-by-side diffs is available in the repository. I'm happy to refine the code based on your feedback and would appreciate any guidance on moving this forward.

Best regards,
Eric
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>



_______________________________________________

Tcl-Core mailing list

Tcl...@li...<mailto:Tcl...@li...>

https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
--
________________________________
Florent MERLET
4 rue Johann Strauss
Logement 7
86180 BUXEROLLES
________________________________
Mél. : flo...@gm...<mailto:flo...@gm...>
Tél. : 06 70 00 63 48
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
--
________________________________
Florent MERLET
4 rue Johann Strauss
Logement 7
86180 BUXEROLLES
________________________________
Mél. : flo...@gm...<mailto:flo...@gm...>
Tél. : 06 70 00 63 48
--
________________________________
Florent MERLET
4 rue Johann Strauss
Logement 7
86180 BUXEROLLES
________________________________
Mél. : flo...@gm...<mailto:flo...@gm...>
Tél. : 06 70 00 63 48

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[Donald P. <d.g...@co...>]

> 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

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[Florent M. <flo...@gm...>]

if {=} is a valid string, does it mean it has ever been used in the code 
base ?

in tcl repro : 
https://github.com/search?q=repo%3Atcltk%2Ftcl%20%7B%3D%7D&type=code

  one occurence in tools/regexpTestLib.tcl 
<https://github.com/tcltk/tcl/blob/a9f6ab7dba8851da58fec404aa3fa4679bac0e93/tools/regexpTestLib.tcl#L198>

=> if {[regexp {=} $flags] == 1} # (false positive)

in tk repro : 
https://github.com/search?q=repo%3Atcltk%2Ftk%20%7B%3D%7D&type=code

no occurence

in tcllib repro : 
https://github.com/search?q=repo%3Atcltk%2Ftcllib%20{%3D}&type=code

no occurence

in tklib repro : 
https://github.com/search?q=repo%3Atcltk%2Ftklib%20{%3D}&type=code

no occurence.

I don't see any breakage there.

Le 21/10/2025 à 21:11, da Silva, Peter J a écrit :
>
> If “{=}” is detected inside tokens this will cause all kinds of 
> breakage that is going to be a lot harder to keep track of than 
> “$(...)”, because right now “{=}” is a valid string in Tcl.
>
> The {*} special case at the beginning of an argument was safe because 
> no valid Tcl code could have {*}... as an element of a list.
>
> *From: *Florent Merlet <flo...@gm...>
> *Date: *Tuesday, October 21, 2025 at 14:05
> *To: *tc...@ro... <tc...@ro...>
> *Cc: *tcl...@li... <tcl...@li...>
> *Subject: *Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - 
> $(expr) Syntax
>
> Yes you are right, I was wrong, {*} is not implemented into 
> Tcl_ParseToken. There is no need for it. But it can't be the same for 
> an {=} prefix : it should be detected inside tokens. Florent Le 
> 21/10/2025 à 20: 54, EricT a écrit : I don't think
>
> Yes you are right, I was wrong,  {*} is not implemented into 
> Tcl_ParseToken.
>
> There is no need for it.
>
> But it can't be the same for an {=} prefix : it should be detected 
> inside tokens.
>
> Florent
>
> Le 21/10/2025 à 20:54, EricT a écrit :
>
>     I don't think you are correct about {*} in a bareword that's not
>     in quotes:
>
>     % proc foo args {puts /$args/}
>     % foo something{*}{1 + 2 + 3}suffix
>     /something\{*\}\{1 + 2 + 3\}suffix/
>     % foo something{*}{1+2+3}suffix
>     /something{*}{1+2+3}suffix/
>
>     % foo {*}{1 2 3}
>     /1 2 3/
>
>     % foo {*}"1 2 3"
>     /1 2 3/
>
>     % foo {*}"123"
>     /123/
>
>     In either of the first 2 cases, it is inserting the {*}{...} as
>     simply text, it is not removing the {*} nor the enclosing {...}
>     and then expanding it to a list. However, it does do all those
>     steps in the 3rd - 5th cases because {*} begins the word.
>
>     Eric
>
>     On Tue, Oct 21, 2025 at 11:37 AM EricT <tw...@gm...> wrote:
>
>         Ok, so from what I can tell, you are saying that your {=} will
>         not substitute if inside of "quotes {=}..." or barewords.
>
>         Here's $(expr) today:
>
>         (bin) 1 % set foo "abc $(1 + 2 + 3) def"
>         abc 6 def
>         (bin) 2 % set foo something$(1 + 2 + 3)
>         something6
>         (bin) 3 % string range "abcdef" 1 end-$(3-2)
>         bcde
>         (bin) 4 % set n 3
>         3
>         (bin) 5 % string range "abcdef" 1 end-$($n-2)
>         bcde
>
>         Can your proposed {=} do this, because [expr] can do it too.
>         And therefore so can $(expr).
>
>         Eric
>
>         On Tue, Oct 21, 2025 at 11:24 AM Florent Merlet
>         <flo...@gm...> wrote:
>
>             Le 21/10/2025 à 19:16, EricT a écrit :
>
>                 The code that handles {*} is somewhat simple because
>                 it begins at a word boundary only:
>
>                 % set foo "abc {*}{1 +2 +3}"
>
>                 abc {*}{1 +2 +3}
>
>                 % set foo something{*}{1 + 2 + 3}suffix
>
>                 wrong # args: should be "set varName ?newValue?"
>
>                 That means that if his {=} code is implemented the
>                 same as {*} the above is what you will get.
>
>             Your coding experiment shows precisely that {*} doesn't
>             work only at a word boundary.
>
>             if {*} were not detected, « set » would not have
>             complained : it would have silently set foo as
>             "something{*}{1 + 2 + 3}suffix"
>
>             But, as  {*} has been detected, it then evaluates 
>             something like :
>
>             % set foo something1 2 3suffix  # (? to be checked ?)
>
>             This gives at least 4 arguments to « set », so you got
>             this error.
>
>             That means that if his {=} code is implemented the same as
>             {*}, the interpreter would have computed the expression
>             1+2+3 and returned the number 6, so that the variable foo
>             would have been set to « something6suffix ».
>
>             {*} is ignored only between quotes. This is'nt an error :
>
>             % set foo "something{*}{1 + 2 + 3}suffix"
>
>             -> something{*}{1 + 2 + 3}suffix
>
>                 On the other hand, $(expr) works everywhere $var
>                 works. That is why it can be implemented in ~100 lines
>                 of code.
>
>                 But again, I may be wrong, I was hoping to hear from
>                 Florent on this.
>
>                 Eric
>
>                 On Tue, Oct 21, 2025 at 6:00 AM Zaumseil René via
>                 Tcl-Core <tcl...@li...> wrote:
>
>                     Hello Eric
>
>                     A solution to the second point is also in the mail
>                     from Florent Merlot with extending {=}
>
>                     The third point is about a radical change with
>                     removing the $-sign to access variables, p.e.
>                     x=y+a. This is way out of current proposals.
>
>                     Regards
>
>                     rene
>
>                     *Von:*EricT <tw...@gm...>
>                     *Gesendet:* Dienstag, 21. Oktober 2025 14:53
>                     *An:* Zaumseil René <RZa...@kk...>
>                     *Cc:* tc...@ro...;
>                     tcl...@li...; et...@ro...
>                     *Betreff:* Re: [TCLCORE] [Ext] Prototype
>                     Implementation of TIP 672 - $(expr) Syntax
>
>                     The main reason for the $(...) syntax is to
>                     encourage the use of safer, compiled, expression
>                     code. Since it would also be easier to read and
>                     write, users would gravitate to its use and
>                     automatically get the benefit of braced expr code.
>
>                     The secondary reason is that many have complained
>                     about [expr {}] being, not as clean syntax as they
>                     would like for expression handling. So, like $var
>                     instead of [set var] a $(...) shorthand for [expr
>                     {...}].
>
>                     I looked at TIP 647, is that the one you really
>                     meant, I saw only a discussion on
>                     Tk_ConfigureWidgets().
>
>                     Can you elaborate on your 3rd point? I don't quite
>                     understand.
>
>                     Eric
>
>                     On Tue, Oct 21, 2025 at 1:36 AM Zaumseil René via
>                     Tcl-Core <tcl...@li...> wrote:
>
>                         Hello
>
>                         I currently do not see the benefit of this
>                         proposal, except some char less to type.
>
>                         IMHO expr has some problems or room for
>                         enhancements:
>
>                          1. Double evaluation of arguments
>
>                         Could be solved with a new command with only 1
>                         argument
>
>                          2. Returns only one value
>
>                         See p.e. tip 647 syntax
>
>                          3. Access to tcl-variables with $-syntax
>
>                         This would require a new expression parser
>
>                          4. Anything else?
>
>                         Do the tip 672 solve one of these points?
>
>                         Regards
>
>                         rene
>
>                         *Von:*EricT <tw...@gm...>
>                         *Gesendet:* Freitag, 17. Oktober 2025 23:22
>                         *An:* tcl...@li...
>                         *Cc:* et...@ro...
>                         *Betreff:* [Ext] [TCLCORE] Prototype
>                         Implementation of TIP 672 - $(expr) Syntax
>
>                         Hello Tcl Core Team,
>
>                         I have developed a working prototype
>                         implementation of TIP 672, which adds the
>                         $(expression) syntax as a more intuitive
>                         alternative to [expr {expression}].
>
>                         Repository:
>                         https://github.com/rocketship88/tcl-tip-672-prototype
>                         <https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=kOgnKtNg5S0p_z-nZS7HAnBrb0GrBKOlYvbsUmtlt7w&e=>
>
>                         The implementation is minimal, modifying only
>                         two files (tclParse.c and tclNamesp.c) with
>                         approximately 100 lines of changes. The key
>                         modification converts the existing two-way
>                         branch in Tcl_ParseVarName to a three-way
>                         branch, with the new path handling $(...) by
>                         creating a synthetic [expr {...}] command string.
>
>                         Key Accomplishments:
>
>                         Full bytecode compilation: The synthetic
>                         string approach integrates seamlessly with the
>                         existing compiler, producing identical
>                         optimized bytecode as [expr {...}]. The
>                         disassembler output (shown in the README)
>                         demonstrates efficient variable loading with
>                         no runtime parsing overhead.
>
>                         Proven approach: Jim Tcl has used this syntax
>                         successfully for years
>
>                         Comprehensive testing: Works correctly with
>                         string interpolation, variable scoping, error
>                         handling, and interactive mode
>
>                         Known Limitations:
>
>                         Memory leak: The synthetic string is allocated
>                         but not tracked for cleanup in Tcl_FreeParse.
>                         This requires core team guidance on the
>                         preferred solution (modify Tcl_Parse structure
>                         vs. thread-local tracking).
>
>                         Error messages: Currently show the synthetic
>                         command rather than the original $(...)
>                         syntax, though this is arguably helpful for
>                         debugging.
>
>                         Questions for the Team:
>
>                         What is the preferred approach for tracking
>                         synthetic strings for cleanup?
>                         Is this prototype architecture acceptable for
>                         Tcl 9.x?
>                         Are there concerns with the synthetic string
>                         approach that I should address?
>
>                         The complete implementation with side-by-side
>                         diffs is available in the repository. I'm
>                         happy to refine the code based on your
>                         feedback and would appreciate any guidance on
>                         moving this forward.
>
>                         Best regards,
>                         Eric
>
>                         _______________________________________________
>                         Tcl-Core mailing list
>                         Tcl...@li...
>                         https://lists.sourceforge.net/lists/listinfo/tcl-core
>                         <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
>
>                     _______________________________________________
>                     Tcl-Core mailing list
>                     Tcl...@li...
>                     https://lists.sourceforge.net/lists/listinfo/tcl-core
>                     <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
>
>
>
>
>                 _______________________________________________
>
>                 Tcl-Core mailing list
>
>                 Tcl...@li...
>
>                 https://lists.sourceforge.net/lists/listinfo/tcl-core <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
>
>             -- 
>
>             ------------------------------------------------------------------------
>
>             *Florent MERLET*
>             /4 rue Johann Strauss
>             Logement 7
>             86180 BUXEROLLES/
>
>             ------------------------------------------------------------------------
>
>             *Mél.* : /flo...@gm.../
>             *Tél.* : /06 70 00 63 48/
>
>             _______________________________________________
>             Tcl-Core mailing list
>             Tcl...@li...
>             https://lists.sourceforge.net/lists/listinfo/tcl-core
>             <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=Ue0Y8Sd9tMEcd43zJo6bc0VdE3lLAHbuz62qIynwAba8R82zTxrb_EjbFHdJe8KA&s=njEPEjVrHlq4lgfuavxY1_8_vIDvpZtGrlJ1qkG1-j4&e=>
>
> -- 
>
> ------------------------------------------------------------------------
>
> *Florent MERLET*
> /4 rue Johann Strauss
> Logement 7
> 86180 BUXEROLLES/
>
> ------------------------------------------------------------------------
>
> *Mél.* : /flo...@gm.../
> *Tél.* : /06 70 00 63 48/
>
-- 
------------------------------------------------------------------------
*Florent MERLET*
/4 rue Johann Strauss
Logement 7
86180 BUXEROLLES/
------------------------------------------------------------------------
*Mél.* : /flo...@gm.../
*Tél.* : /06 70 00 63 48/

Re: [TCLCORE] CFV Warning - TIP 733

[Kevin W. <kw...@co...>]

Hi Emiliano,

Thank you for the feedback. I will review it carefully. 

Thanks, 
Kevin

> On Oct 21, 2025, at 2:53 PM, Emiliano <emi...@gm...> wrote:
> 
> On Sat, 18 Oct 2025 17:07:03 -0400
> Kevin Walzer <kw...@co...> wrote:
> 
> Hi Kevin
> 
> This is an amazing work, providing a long awaited feature. Thanks !!
> 
> I started testing tka11y branch on X11 (linux, x86_64). So far, I've been able
> to find these issues
> 
> * The following line in the configure script is not required to build with
>  atk support. Gtk is not needed.
> 
>     && pkg-config --exists gtk+-3.0 \
> 
> * Starting wish shows a short but visible delay in which the default
>  root window is mapped on screen (200x200). This is most noticeable
>  starting applications such as tkcon, in which the root window is
>  displayed and then withdrawn.
>  This delay is in Tk initialization, not process initialization;
>  loading Tk in a child interpreter shows the same delay.
> 
> * Test textWind-17.10 (peer widget window configuration test) hangs, and
>  closing the tktest window afterwards segfaults.
>  I was unable to isolate this hang completely. Simply running the text
>  tests with TESTFLAGS="-file text*" doesn't hang, so it must depend on
>  something that runs earlier in the test suite.
>  Also, can't say anything about any further tests in the test suite.
> 
> * Widgets must be mapped before using [tk accessible get_acc_*]
>  with them. Example
> 
>  # ---- unmapped.tcl
>  pack [entry .e]
>  tk accessible add_acc_object .e
>  puts [tk accessible get_acc_role .e]
>  # ----
>  $ ./wish9.1  unmapped.tcl
>  No table found. You must set the accessibility role first.
> 
>  # ---- mapped.tcl
>  pack [entry .e]
>  tk accessible add_acc_object .e
>  update
>  puts [tk accessible get_acc_role .e]
>  # ----
>  $ ./wish9.1 mapped.tcl
>  Entry
> 
> * The data in commands [tk accessible {get|set}_acc_*] is not multi
>  interp safe. Running the folowing code
> 
>  # ---- childinterp.tcl
>  pack [entry .e]
>  tk accessible add_acc_object .e
>  update
>  after 2000 {
>    puts "before: [tk accessible get_acc_role .e]"
>    # create a new Tk application and then delete it
>    interp create i
>    i eval {package require Tk}
>    interp delete i
>    # we can no longer access the accessibility data tables
>    catch {tk accessible get_acc_role .e} err od
>    puts "after: $err\n$od"
>    exit
>  }
>  # ----
> 
>  results in (return options dictionary formatted)
> 
>  $ ./wish9.1 childinterp.tcl
>  before: Entry
>  after: No table found. You must set the accessibility role first.
>  -code 1 -level 0 -errorstack {INNER {invokeStk tk accessible get_acc_role .e}}
>  -errorcode NONE -errorinfo {No table found. You must set the accessibility role first.
>      while executing
>  "tk accessible get_acc_role .e"} -errorline 1
> 
>  The solution here is simple: declare and initialize TkAccessibilityObject
>  as NULL
> 
>  Tcl_HashTable *TkAccessibilityObject = NULL;
> 
>  and only allocate and initialize as hash table if NULL in the
>  TkAccessibility_Init function
> 
>  if (!TkAccessibilityObject) {
>    TkAccessibilityObject = (Tcl_HashTable *)ckalloc(sizeof(Tcl_HashTable));
>    Tcl_InitHashTable(TkAccessibilityObject, TCL_ONE_WORD_KEYS);
>  }
> 
> * When widgets are destroyed, the hash tables are not cleaned up, at least
>  the TkAccessibilityObject hash table from generic/tkAccessibility.c .
>  Even recreating a widget with the same pathname and class will,
>  most likely, result in a different tkwin pointer, resulting in an ever
>  growing table with lots of unused entries.
>  Can't say anything about the GLib based hash tables as I don't know how
>  they work.
>  I see there's an event handler for widget deletion in
>  unix/tkUnixAccessibility.c , but there's no cleanup on the above mentioned
>  hash table there. I guess the same applies to both Win and Mac specific
>  code.
> 
> Regards
> 
> --
> Emiliano
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[Donald P. <d.g...@co...>]

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

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[da S. P. J <pet...@fl...>]

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

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[Florent M. <flo...@gm...>]

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/

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[Florent M. <flo...@gm...>]

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/

Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

[EricT <tw...@gm...>]

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
>>
>

Re: [TCLCORE] CFV Warning - TIP 733

[Emiliano <emi...@gm...>]

On Sat, 18 Oct 2025 17:07:03 -0400
Kevin Walzer <kw...@co...> wrote:

Hi Kevin

This is an amazing work, providing a long awaited feature. Thanks !!

I started testing tka11y branch on X11 (linux, x86_64). So far, I've been able
to find these issues

* The following line in the configure script is not required to build with
  atk support. Gtk is not needed.

     && pkg-config --exists gtk+-3.0 \

* Starting wish shows a short but visible delay in which the default
  root window is mapped on screen (200x200). This is most noticeable
  starting applications such as tkcon, in which the root window is
  displayed and then withdrawn.
  This delay is in Tk initialization, not process initialization;
  loading Tk in a child interpreter shows the same delay.

* Test textWind-17.10 (peer widget window configuration test) hangs, and
  closing the tktest window afterwards segfaults.
  I was unable to isolate this hang completely. Simply running the text
  tests with TESTFLAGS="-file text*" doesn't hang, so it must depend on
  something that runs earlier in the test suite.
  Also, can't say anything about any further tests in the test suite.

* Widgets must be mapped before using [tk accessible get_acc_*]
  with them. Example

  # ---- unmapped.tcl
  pack [entry .e]
  tk accessible add_acc_object .e
  puts [tk accessible get_acc_role .e]
  # ----
  $ ./wish9.1  unmapped.tcl
  No table found. You must set the accessibility role first.

  # ---- mapped.tcl
  pack [entry .e]
  tk accessible add_acc_object .e
  update
  puts [tk accessible get_acc_role .e]
  # ----
  $ ./wish9.1 mapped.tcl
  Entry

* The data in commands [tk accessible {get|set}_acc_*] is not multi
  interp safe. Running the folowing code

  # ---- childinterp.tcl
  pack [entry .e]
  tk accessible add_acc_object .e
  update
  after 2000 {
    puts "before: [tk accessible get_acc_role .e]"
    # create a new Tk application and then delete it
    interp create i
    i eval {package require Tk}
    interp delete i
    # we can no longer access the accessibility data tables
    catch {tk accessible get_acc_role .e} err od
    puts "after: $err\n$od"
    exit
  }
  # ----

  results in (return options dictionary formatted)

  $ ./wish9.1 childinterp.tcl 
  before: Entry
  after: No table found. You must set the accessibility role first.
  -code 1 -level 0 -errorstack {INNER {invokeStk tk accessible get_acc_role .e}}
  -errorcode NONE -errorinfo {No table found. You must set the accessibility role first.
      while executing
  "tk accessible get_acc_role .e"} -errorline 1

  The solution here is simple: declare and initialize TkAccessibilityObject
  as NULL

  Tcl_HashTable *TkAccessibilityObject = NULL;

  and only allocate and initialize as hash table if NULL in the
  TkAccessibility_Init function

  if (!TkAccessibilityObject) {
    TkAccessibilityObject = (Tcl_HashTable *)ckalloc(sizeof(Tcl_HashTable));
    Tcl_InitHashTable(TkAccessibilityObject, TCL_ONE_WORD_KEYS);
  }

* When widgets are destroyed, the hash tables are not cleaned up, at least
  the TkAccessibilityObject hash table from generic/tkAccessibility.c .
  Even recreating a widget with the same pathname and class will,
  most likely, result in a different tkwin pointer, resulting in an ever
  growing table with lots of unused entries.
  Can't say anything about the GLib based hash tables as I don't know how
  they work.
  I see there's an event handler for widget deletion in
  unix/tkUnixAccessibility.c , but there's no cleanup on the above mentioned
  hash table there. I guess the same applies to both Win and Mac specific
  code.

Regards

-- 
Emiliano