tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] Update - tka11y

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

I think I’ve addressed these. 

> On Oct 27, 2025, at 4:11 AM, apn...@ya... wrote:
> 
> Confirmed the crash is fixed. Some additional anomalies between Tk and Ttk widgets noticed. Not sure if these are bugs or not. Reporting FYI
> 
> When you tab to non-ttk checkbuttons and radiobuttons , they narrate the label AND whether they are "checked/not checked". However, ttk::checkbuttons and ttk::radiobuttons narrate the label but not if they are checked/not checked.
> 
> When tabbed to get focus, ttk::spinbox narrates the current value in the entry. However, it does not narrate the new value if up/down arrow are used to cycle through the values. On the other hand, the non-ttk combobox does narrate new values when cycling using arrows.
> 
> Toggleswitch does narrate when it is toggled but the initial focus narrates as not selected when in fact it is selected.
> 
> -----Original Message-----
> From: Kevin Walzer <kw...@co...>
> Sent: Monday, October 27, 2025 3:13 AM
> To: apn...@ya...; tcl...@li...
> Subject: Re: [TCLCORE] Update - tka11y/
> 
> Hi Ashok,
> 
> Thank you so much for your additional testing. Please see my comments below:
> 
>> On 10/26/25 12:54 AM, apn...@ya... wrote:
>> - Hovering the mouse over a label or button or other text does not narrate
>> the text. Tabbing to the widget however does narrate the text. Hovering over
>> menus also does narrate the menu item. Note that with native Windows
>> applications, text does get narrated when hovering with the mouse even
>> without focus. If there is a window (of some native application) with text
>> *below* the Tk widget, the text in that window gets narrated instead (again,
>> on a mouse hover).
> 
> My design is built around keyboard navigation and syncing Tk focus
> events with accessibility focus to fire the appropriate notifications to
> the screen reader to narrate something, so mouse events have not been
> taken into consideration. Users of a screen reader are less likely to
> need mouse support. Any screen reader activity with mouse events is
> default behavior for the platform.
> 
> Here is what I observe as the native behavior on each platform:
> 
> 1. On macOS, VoiceOver does not respond to mouse events at all. It's not
> an expectation to have the widget value or text string narrated when a
> mouse passes over it. Since macOS is the first platform-specific
> implementation I worked on, that convention informed my approach to the
> other platforms.
> 
> 2. On Windows, I see the behavior you are describing - moving the mouse
> causes NVDA to say "window" without any additional detail on the widget
> (usually because that is what has focus). Keyboard navigation is
> required to get the full widget data.
> 
> 3. On Linux, Orca does narrate widgets and their text/title/description
> on mouse events. When I was developing X11 accessibility, this
> functionality was a bit misleading, because keyboard navigation
> initially did NOT trigger narration of the widget details. Keyboard
> navigation now works correctly.
> 
> Additional research shows that MSAA does not have any kind of built-in
> support for hover events; UI Automation does, and that is likely what
> you are seeing when you get a widget fully narrated after an <Enter>
> event.  I've played with a few ideas to see if we can fake this behavior
> with MSAA, and nothing has really worked.  Since MSAA lacks support for
> hover events and UIA integration is currently very limited, the
> narration with mouse events can't be supported at this time.
> 
>> - When typing into the text widget, last letter is repeated (for example,
>> typing "word" narrates w, o, r, d, d)
> This has been corrected.
>> 
>> - There is also a crash on exit for which I have submitted a ticket.
> 
> I committed a fix that appears to solve the crash-on-shutdown issue;
> please test.
> 
> Unless you or anyone else finds additional issues of substance in the
> next week, I plan to call for a vote so we can get this into Tk for the
> next alpha release of 9.1.
> 
> --Kevin
> 
> 
> 

Re: [TCLCORE] Update - tka11y/

[<apn...@ya...>]

Confirmed the crash is fixed. Some additional anomalies between Tk and Ttk widgets noticed. Not sure if these are bugs or not. Reporting FYI

When you tab to non-ttk checkbuttons and radiobuttons , they narrate the label AND whether they are "checked/not checked". However, ttk::checkbuttons and ttk::radiobuttons narrate the label but not if they are checked/not checked.

When tabbed to get focus, ttk::spinbox narrates the current value in the entry. However, it does not narrate the new value if up/down arrow are used to cycle through the values. On the other hand, the non-ttk combobox does narrate new values when cycling using arrows.

Toggleswitch does narrate when it is toggled but the initial focus narrates as not selected when in fact it is selected.

-----Original Message-----
From: Kevin Walzer <kw...@co...> 
Sent: Monday, October 27, 2025 3:13 AM
To: apn...@ya...; tcl...@li...
Subject: Re: [TCLCORE] Update - tka11y/

Hi Ashok,

Thank you so much for your additional testing. Please see my comments below:

On 10/26/25 12:54 AM, apn...@ya... wrote:
> - Hovering the mouse over a label or button or other text does not narrate
> the text. Tabbing to the widget however does narrate the text. Hovering over
> menus also does narrate the menu item. Note that with native Windows
> applications, text does get narrated when hovering with the mouse even
> without focus. If there is a window (of some native application) with text
> *below* the Tk widget, the text in that window gets narrated instead (again,
> on a mouse hover).

My design is built around keyboard navigation and syncing Tk focus 
events with accessibility focus to fire the appropriate notifications to 
the screen reader to narrate something, so mouse events have not been 
taken into consideration. Users of a screen reader are less likely to 
need mouse support. Any screen reader activity with mouse events is 
default behavior for the platform.

Here is what I observe as the native behavior on each platform:

1. On macOS, VoiceOver does not respond to mouse events at all. It's not 
an expectation to have the widget value or text string narrated when a 
mouse passes over it. Since macOS is the first platform-specific 
implementation I worked on, that convention informed my approach to the 
other platforms.

2. On Windows, I see the behavior you are describing - moving the mouse 
causes NVDA to say "window" without any additional detail on the widget 
(usually because that is what has focus). Keyboard navigation is 
required to get the full widget data.

3. On Linux, Orca does narrate widgets and their text/title/description 
on mouse events. When I was developing X11 accessibility, this 
functionality was a bit misleading, because keyboard navigation 
initially did NOT trigger narration of the widget details. Keyboard 
navigation now works correctly.

Additional research shows that MSAA does not have any kind of built-in 
support for hover events; UI Automation does, and that is likely what 
you are seeing when you get a widget fully narrated after an <Enter> 
event.  I've played with a few ideas to see if we can fake this behavior 
with MSAA, and nothing has really worked.  Since MSAA lacks support for 
hover events and UIA integration is currently very limited, the 
narration with mouse events can't be supported at this time.

> - When typing into the text widget, last letter is repeated (for example,
> typing "word" narrates w, o, r, d, d)
This has been corrected.
>
> - There is also a crash on exit for which I have submitted a ticket.

I committed a fix that appears to solve the crash-on-shutdown issue; 
please test.

Unless you or anyone else finds additional issues of substance in the 
next week, I plan to call for a vote so we can get this into Tk for the 
next alpha release of 9.1.

--Kevin

Re: [TCLCORE] Update - tka11y/

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

Hi Ashok,

Thank you so much for your additional testing. Please see my comments below:

On 10/26/25 12:54 AM, apn...@ya... wrote:
> - Hovering the mouse over a label or button or other text does not narrate
> the text. Tabbing to the widget however does narrate the text. Hovering over
> menus also does narrate the menu item. Note that with native Windows
> applications, text does get narrated when hovering with the mouse even
> without focus. If there is a window (of some native application) with text
> *below* the Tk widget, the text in that window gets narrated instead (again,
> on a mouse hover).

My design is built around keyboard navigation and syncing Tk focus 
events with accessibility focus to fire the appropriate notifications to 
the screen reader to narrate something, so mouse events have not been 
taken into consideration. Users of a screen reader are less likely to 
need mouse support. Any screen reader activity with mouse events is 
default behavior for the platform.

Here is what I observe as the native behavior on each platform:

1. On macOS, VoiceOver does not respond to mouse events at all. It's not 
an expectation to have the widget value or text string narrated when a 
mouse passes over it. Since macOS is the first platform-specific 
implementation I worked on, that convention informed my approach to the 
other platforms.

2. On Windows, I see the behavior you are describing - moving the mouse 
causes NVDA to say "window" without any additional detail on the widget 
(usually because that is what has focus). Keyboard navigation is 
required to get the full widget data.

3. On Linux, Orca does narrate widgets and their text/title/description 
on mouse events. When I was developing X11 accessibility, this 
functionality was a bit misleading, because keyboard navigation 
initially did NOT trigger narration of the widget details. Keyboard 
navigation now works correctly.

Additional research shows that MSAA does not have any kind of built-in 
support for hover events; UI Automation does, and that is likely what 
you are seeing when you get a widget fully narrated after an <Enter> 
event.  I've played with a few ideas to see if we can fake this behavior 
with MSAA, and nothing has really worked.  Since MSAA lacks support for 
hover events and UIA integration is currently very limited, the 
narration with mouse events can't be supported at this time.

> - When typing into the text widget, last letter is repeated (for example,
> typing "word" narrates w, o, r, d, d)
This has been corrected.
>
> - There is also a crash on exit for which I have submitted a ticket.

I committed a fix that appears to solve the crash-on-shutdown issue; 
please test.

Unless you or anyone else finds additional issues of substance in the 
next week, I plan to call for a vote so we can get this into Tk for the 
next alpha release of 9.1.

--Kevin

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

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

On the chat Schelte pointed out that this approach would have difficulty 
distinguishing array references from mathfunc calls - e.g. does 
`min(2,3)` mean 2 or the value at index "2,3" in array min.

I think resolving this without nasty surprises would require disallowing 
bareword array references, so `min(2,3)` would always call function 
min().  I you really need a value from an array you can use e.g. 
`$min(2,3)` to have it pre-substituted, with the caveat that odd things 
may happen if that value is not a single number.

Colin.

On 25/10/2025 17:17, Colin Macleod via Tcl-Core wrote:
>
> (Sorry, I just can't stay away from the bikeshed)  :-)
>
> Kevin mentions the idea of having expression evaluation interpret bare 
> words as variable references without requiring $ in front.
>
> On 21/10/2025 03:30, Kevin Kenny wrote:
>
>> (I'd actually favor {$} over {=}, and instead reserve {=} for the 
>> possibility of a new 'little language' for less cumbersome 
>> expressions (in particular, automatic $-substitution of barewords, 
>> and implementation of = for assignment.
> It occurs to me now that an expr alternative which does this can avoid 
> the whole double substitution issue.  If you can write x*2-3 instead 
> of $x*2-3 there's no need to brace the expression because x cannot be 
> prematurely substituted before the expression code sees it.
>
> If `=` was defined to concatenate its arguments and then treat the 
> result as an expression where barewords are interpreted as variable 
> references, you could write [= x*2-3] to do this calculation in a form 
> which is both safe, compact, and fully conforms to the existing 
> dodekalogue rules.
>
> As with my proposal in tip 676, this probably needs to be restricted 
> to numeric and boolean operations, string literals would be difficult 
> to accommodate.
>
> Of course it would still be possible to write $ substitutions within 
> the expression, but this would not normally be needed and the 
> documentation should warn that this is risky.
>
> Substitutions of [command] would work as long as command returns a 
> single numeric or boolean value. However if that value gets 
> concatenated into a string its numeric representation will be 
> shimmered away. It may be possible to avoid this if [command] is given 
> as a separate argument, i.e. [= 2* [llength $list] -1] not [= 
> 2*[llength $list]-1], by checking for a numeric representation before 
> concatenating arguments.
>
> However the main usefulness of this facility would be for short, 
> simple expressions like [= x*2-3] (9 chars) where the verbosity of 
> [expr {$x*2-3}] (15 chars) is cumbersome.  The proposed $(($x*2-3)) is 
> longer (11 chars) *and* requires an update to the dodekalogue, 
> something not to be undertaken lightly.
>
> Colin.
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Update - tka11y/

[<apn...@ya...>]

Trying the latest commit, I noticed some regression from my prior report.

Tested with NVDA on Windows 10.

- Hovering the mouse over a label or button or other text does not narrate
the text. Tabbing to the widget however does narrate the text. Hovering over
menus also does narrate the menu item. Note that with native Windows
applications, text does get narrated when hovering with the mouse even
without focus. If there is a window (of some native application) with text
*below* the Tk widget, the text in that window gets narrated instead (again,
on a mouse hover).

- When typing into the text widget, last letter is repeated (for example,
typing "word" narrates w, o, r, d, d)

- There is also a crash on exit for which I have submitted a ticket.



-----Original Message-----
From: Kevin Walzer <kw...@co...> 
Sent: Monday, October 13, 2025 1:25 AM
To: tcl...@li...
Subject: [TCLCORE] Update - tka11y/

Hi all,

I've received quite a bit of feedback on TIP 733, screen reader support 
for Tk. Thank you. I wanted to provide an update on how I am taking 
action on the input:

1. Language issues / macOS: I have committed a fix that appears to 
address the issue. Please test and let me know if it works.

2. Adding "set" command prefixes to balance out "get" - done.

3. Verbalizing each keypress and prior word in text/entry widgets - In 
process.

4. Wrong error on progress bars - Need to investigate further. The 
intended behavior at this point for active progress bars is simply to 
return "busy" as the value to indicate it is running. If we are getting 
"0.0," does that mean it is inactive?

5. Microsoft Narrator support - Mixed results. Narrator now correctly 
reads button labels. But overall, support for Narrator is proving very 
difficult to implement. After spending months perfecting the Microsoft 
Active Accessibility implementation, which works very well, I do not 
want to have to reinvent the wheel with a full UI Automation 
implementation to support Narrator. After a lot of work, I have settled 
on using the LegacyIAccessible pattern for UIA, which theoretically 
allows MSAA data to drive UIA queries. However, there are significant 
differences in some aspects of the two API's, and the impedance mismatch 
may make it difficult to provide robust support for Narrator. I 
understand that this is the screen reader bundled with Windows, but 
Narrator generally is regarded as inferior to NVDA and JAWS, the two 
major apps in this area. I will keep working on this, but ultimately may 
have to defer perfection in this area to someone who might have more 
expertise with these API's.

6. Crash reports in test suite - on my to-do list once Narrator is 
addressed.

Let me know if you have any questions.

Thanks,

Kevin



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

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

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

Hi Jan,

Regarding "Expression Substitution - Size Difference Mechanism and New
Opportunities":

Thank you for the clarification about TIP 465 and your endorsement of the
$((expr)) syntax! Your refactoring work has actually opened up some
interesting opportunities I wanted to share.

Background on the Size Difference Approach:

In the original implementation, we used a constant size difference
(EXPR_SIZE_DIFF) between the original syntax (e.g., $((expr))) and the
synthetic string ([expr {expr}]). This was necessary because when
TclParseExprSubst creates the synthetic string and stores it in the token,
the token's size reflects the synthetic string length. However, ParseTokens
needs to advance its src and numBytes by the *original* syntax length. By
maintaining a fixed offset between the two representations, we could
calculate the original size as syntheticSize - EXPR_SIZE_DIFF.

New Opportunity from Your Refactoring:

With TclParseExprSubst now being a private function called only from within
ParseTokens, we have the freedom to modify its calling sequence! We could
have it return the actual original size consumed (via an output parameter
or other mechanism), eliminating the need for the constant offset
calculation entirely. This would make the code cleaner and more robust.

Regarding the email I sent you earlier about the issue with missing closing
parentheses - that concern wouldn't be in play with this new approach.
Since we can return to the caller the actual size of the expression (which
we know through the balancing of the ()'s), we can also handle cases where
users accidentally (or purposely) leave off the second trailing ) without
causing negative numBytes values.

What do you think about this?

Best regards,
Eric

On Sat, Oct 25, 2025 at 2:07 AM Jan Nijtmans <jan...@gm...> wrote:

> Op za 25 okt 2025 om 01:34 schreef Phillip Brooks:
> > tags:         trunk, main
> >
> > comment:      TIP #465: Change Rule 8 of the Dodekalogue to Cut Some
> Corner Cases (user: jan.nijtmans)
> >
> >
> > Jan,  Can you confirm whether the current behavior here is correct for
> 9.0 - or is it a bug?  If it is correct behavior, then it seems that the
> $(( expression )) syntax is currently guarded from being recognized as
> valid syntax at least in this context.
> >
> >
> > If it is a bug, can you explain the intent of the change?
>
> Everything you want to know about it (hopefully) can be found
> here:
>      <https://core.tcl-lang.org/tips/doc/trunk/tip/465.md>
>
> It - indeed - means that the $(( ... )) syntax is invalid in Tcl 9.0,
> so it can safely be used for "expression substitution".
>
> I think we should go for this syntax!
>         Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

(Sorry, I just can't stay away from the bikeshed)  :-)

Kevin mentions the idea of having expression evaluation interpret bare 
words as variable references without requiring $ in front.

On 21/10/2025 03:30, Kevin Kenny wrote:

> (I'd actually favor {$} over {=}, and instead reserve {=} for the 
> possibility of a new 'little language' for less cumbersome expressions 
> (in particular, automatic $-substitution of barewords, and 
> implementation of = for assignment.
It occurs to me now that an expr alternative which does this can avoid 
the whole double substitution issue.  If you can write x*2-3 instead of 
$x*2-3 there's no need to brace the expression because x cannot be 
prematurely substituted before the expression code sees it.

If `=` was defined to concatenate its arguments and then treat the 
result as an expression where barewords are interpreted as variable 
references, you could write [= x*2-3] to do this calculation in a form 
which is both safe, compact, and fully conforms to the existing 
dodekalogue rules.

As with my proposal in tip 676, this probably needs to be restricted to 
numeric and boolean operations, string literals would be difficult to 
accommodate.

Of course it would still be possible to write $ substitutions within the 
expression, but this would not normally be needed and the documentation 
should warn that this is risky.

Substitutions of [command] would work as long as command returns a 
single numeric or boolean value. However if that value gets concatenated 
into a string its numeric representation will be shimmered away. It may 
be possible to avoid this if [command] is given as a separate argument, 
i.e. [= 2* [llength $list] -1] not [= 2*[llength $list]-1], by checking 
for a numeric representation before concatenating arguments.

However the main usefulness of this facility would be for short, simple 
expressions like [= x*2-3] (9 chars) where the verbosity of [expr 
{$x*2-3}] (15 chars) is cumbersome.  The proposed $(($x*2-3)) is longer 
(11 chars) *and* requires an update to the dodekalogue, something not to 
be undertaken lightly.

Colin.

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

[Pietro C. <ga...@ga...>]

> On 25 Oct 2025, at 11:07, Jan Nijtmans <jan...@gm...> wrote:
> 
> Op za 25 okt 2025 om 01:34 schreef Phillip Brooks:
>> tags:         trunk, main
>> 
>> comment:      TIP #465: Change Rule 8 of the Dodekalogue to Cut Some Corner Cases (user: jan.nijtmans)
>> 
>> 
>> Jan,  Can you confirm whether the current behavior here is correct for 9.0 - or is it a bug?  If it is correct behavior, then it seems that the $(( expression )) syntax is currently guarded from being recognized as valid syntax at least in this context.
>> 
>> 
>> If it is a bug, can you explain the intent of the change?
> 
> Everything you want to know about it (hopefully) can be found
> here:
>     <https://core.tcl-lang.org/tips/doc/trunk/tip/465.md>
> 
> It - indeed - means that the $(( ... )) syntax is invalid in Tcl 9.0,
> so it can safely be used for "expression substitution".
> 
> I think we should go for this syntax!
>        Jan Nijtmans


Having followed this thread with curiosity but also somewhat disillusioned - given the precedents - I must say I find this a game changer, and something we can't allow ourselves to miss. We have in our hands a backwards compatible *and* nice looking expr shortcut. Wow! I'm all for it!

-- 
Pietro Cerutti
I've pledged to give 10% of income to effective charities and invite you to join me.
https://givingwhatwecan.org

Sent from a small device - please excuse brevity and typos.

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

[Jan N. <jan...@gm...>]

Op za 25 okt 2025 om 01:34 schreef Phillip Brooks:
> tags:         trunk, main
>
> comment:      TIP #465: Change Rule 8 of the Dodekalogue to Cut Some Corner Cases (user: jan.nijtmans)
>
>
> Jan,  Can you confirm whether the current behavior here is correct for 9.0 - or is it a bug?  If it is correct behavior, then it seems that the $(( expression )) syntax is currently guarded from being recognized as valid syntax at least in this context.
>
>
> If it is a bug, can you explain the intent of the change?

Everything you want to know about it (hopefully) can be found
here:
     <https://core.tcl-lang.org/tips/doc/trunk/tip/465.md>

It - indeed - means that the $(( ... )) syntax is invalid in Tcl 9.0,
so it can safely be used for "expression substitution".

I think we should go for this syntax!
        Jan Nijtmans

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

[Phillip B. <phi...@um...>]

I have an update concerning one behavior and the viability of $(( ... )) as
the expr shorthand syntax - one thing that Eric and I discovered in trying
different testcases is that Tcl 8.6 and Tcl 9.0 differ in how they handle
this Tcl code:

array set {} { (index 99 }

puts $((index)


Tcl 8.6 treats an unescaped (index string as an index value and prints the
value 99.

Tcl 9.0 treats $((index) as an invalid input:

invalid character in array index

    while executing

"puts $("

    (file "t.tcl" line 4)


In order to extract the expected value from Tcl 9, the '(' character must
be escaped:


% puts $(\(index)

99


Note also that the trailing ')' character is invalid in both 8.6 and 9.0
where both produce this output:


% array set {} { index) 99 }

% puts $(index))

can't read "(index)": no such element in array

% puts $(index\))

99


While both treat (index) as an invalid index, they produce different error
messages:


8.6:

can't read "((index)": no such element in array


9.0:

invalid character in array index



I ran this through fossil bisect, and found that the change came with this
commit:


% fossil info 378e95c3827e07e7

hash:         378e95c3827e07e77edb1ff47768a8b89b79005d 2022-10-04 16:04:29
UTC

parent:       e89e02bd39217e034402a429b9241f848b00e674 2022-10-04 15:57:51
UTC

merged-from:  102677d930e6206eaa65329fa6d623eaef009b2b 2022-09-29 19:17:10
UTC

child:        2e1f06b6e01e758aaffbfa9a399eec16e7688c74 2022-10-04 18:25:18
UTC

merged-into:  e34bd0f05fa79d65542e0fe45ec3a52df09453e3 2022-10-04 16:06:01
UTC

tags:         trunk, main

comment:      TIP #465: Change Rule 8 of the Dodekalogue to Cut Some Corner
Cases (user: jan.nijtmans)


Jan,  Can you confirm whether the current behavior here is correct for 9.0
- or is it a bug?  If it is correct behavior, then it seems that the $((
expression )) syntax is currently guarded from being recognized as valid
syntax at least in this context.


If it is a bug, can you explain the intent of the change?


Fossil bisect shows this set of results going from core-8-6-branch to main
with good marking 8.6 behavior and bad marking 9.0 behavior:


% fossil bisect bad

bisect complete

  1 BAD     2025-10-23 13:29:59 fe5a2b815496eee4

  2 GOOD    2025-10-01 09:34:18 6f4ed276049067f2

  4 BAD     2023-04-12 18:19:37 0d197907c6441328

  7 BAD     2022-12-16 10:25:02 67c049ff94ddd48f

  8 BAD     2022-11-01 16:13:26 05e443d1725ae9ae

  9 BAD     2022-10-11 15:55:06 0cd124939e1894c0

 11 BAD     2022-10-08 15:43:40 58f6cbaca1610f18

 12 BAD     2022-10-06 10:15:49 ed075af7b197faa6

 13 BAD     2022-10-04 22:05:19 5a5bf81d4c384f25

 14 BAD     2022-10-04 18:25:18 2e1f06b6e01e758a

 15 BAD     2022-10-04 16:04:29 378e95c3827e07e7 CURRENT

 10 GOOD    2022-10-04 15:57:51 e89e02bd39217e03

  6 GOOD    2022-09-19 14:06:59 0b9810772d261993

  5 GOOD    2021-07-23 10:08:35 2e62fe9b610ddccd

  3 GOOD    2019-06-28 22:43:10 309d50a740952c04


Phil

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

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

Hi Jan,

Thank you for the extensive refactoring work! I've downloaded the latest
from the tip-672 branch and can see you picked up my latest changes
including the 3-way configuration.

I haven't made any new changes since then, so you should be working with my
most recent code. I'll review your refactoring and provide feedback.

The creation of TclParseExprSubst() as an internal function and the interp
exprsubst knob make good sense. I appreciate you taking this on!

Eric


On Fri, Oct 24, 2025 at 3:22 AM Jan Nijtmans <jan...@gm...> wrote:

> Op do 23 okt 2025 om 20:17 schreef EricT <tw...@gm...>:
> > For my sections: would converting to spaces-only work for the community?
> I hesitate to change the entire file.
>
> No problem. Three things are - in my opinion - important to be done
> 1) The $() is only acceptable if there is a knob to switch it off. I
>     implemented this knob now (interp exprsubst). If another change
>     is made than $(), we can always decide to remove this.
> 2) Integrating the expr parsing in Tcl_ParseVarName() is not a good
>     idea: It's a public function, which behavior would change. Therefore
>     I refactored it into a new internal function TclParseExprSubst().
> 3) The "subst" command (and the Tcl_SubstObj() function) need
>     new options/flags to handle the new "expression" substitution,
>     separate to "variable" substitution and "command" substitution.
>     That solves the discussion, whether this substitution belongs
>     to "variable" or "command" substitution. I think it is neither ;-)
>
> All of this is available now in the tip-672 branch
>       https://core.tcl-lang.org/tcl/timeline?r=tip-672
>
> Eric, if you make further changes, can you please take the
> files in this branch as your starting point? It's quite a big
> effort to merge the two versions, if I take over your changes,
> but you never take over mine.
>
> Please review!
>
> Thanks!
>         Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

Hi Jan,
I've been thinking about the subject this morning. I m trying to implement
the alternative syntaxe  [( ... )]

I got my head turning form eval to parse and from parse to subst...

Whatever, I have 1 question  about the procedure Tcl_ParseExpr.  This
procedure seems to be used nowhere.

How do we use it ? The idea is to parse an expression, then to subst it to
get a value.

I don't want to go throught a TCL_TOKEN_COMMAND token, but throught a
TCL_TOKEN_SUBEXPR token.

But turning from files to files i can't see any procedure that use it to
get a value from it

Thanks for your help.

Le ven. 24 oct. 2025, 12:22, Jan Nijtmans <jan...@gm...> a écrit :

> Op do 23 okt 2025 om 20:17 schreef EricT <tw...@gm...>:
> > For my sections: would converting to spaces-only work for the community?
> I hesitate to change the entire file.
>
> No problem. Three things are - in my opinion - important to be done
> 1) The $() is only acceptable if there is a knob to switch it off. I
>     implemented this knob now (interp exprsubst). If another change
>     is made than $(), we can always decide to remove this.
> 2) Integrating the expr parsing in Tcl_ParseVarName() is not a good
>     idea: It's a public function, which behavior would change. Therefore
>     I refactored it into a new internal function TclParseExprSubst().
> 3) The "subst" command (and the Tcl_SubstObj() function) need
>     new options/flags to handle the new "expression" substitution,
>     separate to "variable" substitution and "command" substitution.
>     That solves the discussion, whether this substitution belongs
>     to "variable" or "command" substitution. I think it is neither ;-)
>
> All of this is available now in the tip-672 branch
>       https://core.tcl-lang.org/tcl/timeline?r=tip-672
>
> Eric, if you make further changes, can you please take the
> files in this branch as your starting point? It's quite a big
> effort to merge the two versions, if I take over your changes,
> but you never take over mine.
>
> Please review!
>
> Thanks!
>         Jan Nijtmans
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

[TCLCORE] OpenACS/Tcl/Tk conference 2026

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

Dear Tcl/Tk community,

it was announced that the 2026 conference is in Essen in central Germany 
at the "Linuxhotel", which is an open source infra structure.

The "Linuxhotel" has only possibilities on Week Ends and no service at 
all. There is no food. It is not in the town center but in nature 
without much infra structure around. I did not get any offered date.

It was now proposed to do the conference in 2026 again in Vienna in 
June/July. KM is sponsoring again. There is no date request jet and we 
are just starting today.

Any alternate proposals welcome!

Thanks for all,
Harald

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

[Jan N. <jan...@gm...>]

Op do 23 okt 2025 om 20:17 schreef EricT <tw...@gm...>:
> For my sections: would converting to spaces-only work for the community? I hesitate to change the entire file.

No problem. Three things are - in my opinion - important to be done
1) The $() is only acceptable if there is a knob to switch it off. I
    implemented this knob now (interp exprsubst). If another change
    is made than $(), we can always decide to remove this.
2) Integrating the expr parsing in Tcl_ParseVarName() is not a good
    idea: It's a public function, which behavior would change. Therefore
    I refactored it into a new internal function TclParseExprSubst().
3) The "subst" command (and the Tcl_SubstObj() function) need
    new options/flags to handle the new "expression" substitution,
    separate to "variable" substitution and "command" substitution.
    That solves the discussion, whether this substitution belongs
    to "variable" or "command" substitution. I think it is neither ;-)

All of this is available now in the tip-672 branch
      https://core.tcl-lang.org/tcl/timeline?r=tip-672

Eric, if you make further changes, can you please take the
files in this branch as your starting point? It's quite a big
effort to merge the two versions, if I take over your changes,
but you never take over mine.

Please review!

Thanks!
        Jan Nijtmans

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

[bch <bra...@gm...>]

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On Oct 21, 2025, at 01:55, Donal Fellows &lt;don...@ma...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">



<div class="_E_EBlockEntityContainer"><span style="font-family: &quot;Segoe UI&quot;, &quot;Segoe UI Web (West European)&quot;, &quot;Helvetica Neue&quot;, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="entityDelimiterBefore">​</span>
<div style="width: 100%; display: inline-block;" class="_Entity _EType_Quote _EId_Quote _EReadonly_1">
<table id="ReplyWithQuote_Container" style="border: 1.5px solid rgb(237, 235, 233); border-radius: 4px; padding: 4px 0px 4px 4px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0); margin-bottom: 4px;">
<tbody>
<tr>
<td rowspan="2" style="background-color: rgb(200, 198, 196); width: 3.5px; border-radius: 10px; padding: 0px;">
</td>
<td style="font-size: 12px; border-left: 10px solid transparent; border-right: 10px solid transparent; padding: 0px;">
<div style="display: inline; color: rgb(50, 49, 48);">EricT</div>
<div style="display: inline; padding-left: 10px; color: rgb(96, 94, 92);">2025-10-21 04:12</div>
</td>
</tr>
<tr>
<td style="font-size: 14px; color: rgb(50, 49, 48); border-left: 10px solid transparent; border-right: 10px solid transparent; padding: 0px;">
1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.</td>
</tr>
</tbody>
</table>
</div>
<span style="font-family: &quot;Segoe UI&quot;, &quot;Segoe UI Web (West European)&quot;, &quot;Helvetica Neue&quot;, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="entityDelimiterAfter">​</span></div>
<div style="font-family: &quot;Segoe UI&quot;, &quot;Segoe UI Web (West European)&quot;, &quot;Helvetica Neue&quot;, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="elementToProof">
Surely the better shell precedent would be the $((expression)) form? </div></div></blockquote><div><br></div><div><br></div><div>Fwiw, I don’t think looking up to bash/sh for inspiration is where we should be at all. We can do better for Tcl, regardless of how familiar it looks.</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div style="font-family: &quot;Segoe UI&quot;, &quot;Segoe UI Web (West European)&quot;, &quot;Helvetica Neue&quot;, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);" class="elementToProof">That would also be quite a bit less likely to clash with existing use cases.<span style="color: rgb(0, 0, 0);">&nbsp;Hmm, a quick search with
<a href="https://github.com/search?q=%24%28%28+language%3ATcl&amp;type=code">https://github.com/search?q=%24%28%28+language%3ATcl&amp;type=code</a>&nbsp;gives 29 hits (most of which appear to be false positives; the real hits seem to be from one place in JimTcl itself),
 as opposed to 4k hits when looking for $( in Tcl code; two orders of magnitude less usage. One of the
<i>really</i>&nbsp;nice things about a resource like GitHub is that one can <i>quickly</i>&nbsp;search for language syntax features across a lot of code and get a good feeling for practical compatibility.</span></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
While $(([llength $x] - 17)) is no shorter than {=}{[llength $x] - 17}, it's definitely easier to type!</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br></div></div></blockquote><div><br></div><div>I already deal enough w [expr] that it’s not a big deal… but *imagining* typing either of the above, if I had to pick, I think I’d prefer Brian’s modification for the reason of the benefits pointed out by him and Kevin wrt “{*}” precedent in scripts and its adaptable parser implementation.</div><div><br></div><div>“Fixing” empty array w pragmas or similar is also not attractive sounding… it means it’s difficult to know what kind of runtime you’re stepping up to. At its worst, it leads to inscrutable envs like php.ini. This is a thin edge of the wedge we should be looking to avoid.</div><br><blockquote type="cite"><div dir="ltr"><div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
(Eric: Don't lose heart! These discussions are a <i>lot</i>&nbsp;less acrimonious than the discussion over what became {*} was.)&nbsp;</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
Donal.</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>From:</b>&nbsp;EricT &lt;tw...@gm...&gt;<br>
<b>Sent:</b>&nbsp;Tuesday, October 21, 2025 04:11<br>
<b>To:</b>&nbsp;Brian Griffin &lt;bri...@ea...&gt;<br>
<b>Cc:</b>&nbsp;tc...@ro... &lt;tc...@ro...&gt;; Tcl Core List &lt;tcl...@li...&gt;<br>
<b>Subject:</b>&nbsp;Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="direction: ltr;">Thanks for the feedback, Brian! I understand your concern about the semantic distinction between $ (value) and [ ] (execution).<br>
<br>
I'd offer a few thoughts:<br>
<br>
1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.<br>
<br>
2. $ already involves execution: Even $var involves command execution internally (TclGetVar), it's just optimized. The distinction between "value substitution" and "command execution" is somewhat artificial at the implementation level.<br>
<br>
3.&nbsp; expr is special and has historical precedent: Unlike arbitrary commands, expr is used so frequently that syntactic sugar makes sense - similar to how $var is sugar for [set var]. We optimize the common case. I believe there was a time in early Tcl before
 $var existed when [set var] was the only choice - if so, adding $var as syntactic sugar for variable substitution was a usability win. $(expr) follows the same pattern - sugar for the extremely common [expr {...}] case.<br>
<br>
4. Consistency: $(expr) fits the pattern of "$ means substitute something here" - whether a variable, array element, or expression result. Modern languages like Python have embraced similar concepts with f-strings that allow {expression} for inline evaluation.
 $(expr) brings this convenience to Tcl while maintaining our substitution semantics.<br>
<br>
That said, I appreciate the philosophical consistency argument. Do you see the security benefits (auto-bracing) as compelling enough to outweigh the semantic concern?<br>
<br>
</div>
<div style="direction: ltr;">Did you see the email I sent you about lseq? Maybe it landed in your spam folder - that happened once before as I recall.</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">Eric</div>
<div style="direction: ltr;"><br>
</div>
<div><br>
</div>
<div style="direction: ltr;">On Mon, Oct 20, 2025 at 7:19 PM Brian Griffin &lt;<a class="OWAAutoLink" id="OWA804178ca-19c0-2c1c-f2ba-089dcc6f3e84" href="mailto:bri...@ea...">bri...@ea...</a>&gt; wrote:</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div>I like the idea of simplifying expression substitutions.&nbsp; The problem I have is that the '$' is defined to be a value substitution. Running a command (execution) is a [] substitution, not a '$' substitution.&nbsp; Conflating the two modes of substitution can
 cause confusion for newbies, and even experienced programmers.&nbsp;</div>
<div><br>
</div>
<div>I recognize that this view is a very subtle distinction, but I think it's important.</div>
<div><br>
</div>
<div>Think of it like conflating * vs &amp; in C. &nbsp;(Maybe not that bad, but similar)</div>
<div><br>
</div>
<div>-Brian</div>
<div><br>
</div>
<blockquote>
<div>On Oct 20, 2025, at 07:22, EricT &lt;<a class="OWAAutoLink" id="OWA485216db-5c80-ecb7-38fe-a224c563294c" href="mailto:tw...@gm...">tw...@gm...</a>&gt; wrote:</div>
<div><br>
</div>
<div style="direction: ltr;">Regarding the discussion in the telco today. If the incompatibility discussed is the&nbsp;known empty array issue, then for that I would propose the following:</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">There could be a pragma or tcl_dollar_expr global variable with several settings.</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">1. Work in compatibility mode, i.e. as though the feature was not implemented at all.&nbsp;</div>
<div style="direction: ltr;">2. Work in diagnostic mode, throw an error for any $(...) use</div>
<div style="direction: ltr;">3. Work in full implementation mode</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">The code to do this, given a global C variable to check would be trivial.&nbsp;</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">This value could default to 1. for at least 9.1 or 9.2 but there could be an option, similar to tclsh -encoding, that would allow the pragma variable to be set before any init script code is run. This would give developers the opportunity&nbsp;to
 set the variable to mode 2 in order to easily track down uses of $(index) before any code were to begin using $(expr).&nbsp;</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">I think it would be quite rare if this syntax change would affect binary extensions, so it should be only with script level coding.&nbsp;</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">The fix to any code that is using the empty array variable, is to change from,</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">&nbsp; &nbsp; set val $(index)</div>
<div style="direction: ltr;">&nbsp; &nbsp; set val $($var)&nbsp; - or any other valid index string</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">to</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">&nbsp; &nbsp;set val ${(index)}</div>
<div style="direction: ltr;">&nbsp; &nbsp;set val ${($var)}</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">Likewise for any other use of the $(...) substitution in current use.</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">This change can begin to be made right away, since it is a compatible&nbsp;syntax that does not change the semantics.&nbsp; Once all the init time script code or packages that use the un-braced&nbsp;syntax are found and changed, the feature could
 begin to be used by those who are interested.</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">On the other hand, if the incompatibility&nbsp;is something other than this empty array, I'd be most appreciative to know what it is.</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">thanks</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">Eric</div>
<div style="direction: ltr;"><br>
</div>
<div><br>
</div>
<div style="direction: ltr;">On Sun, Oct 19, 2025 at 3:44 AM EricT &lt;<a class="OWAAutoLink" id="OWA0301b487-6449-46f4-f565-a768f03d4ed8" href="mailto:tw...@gm...">tw...@gm...</a>&gt; wrote:</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div style="direction: ltr;">Harald,<br>
<br>
Thank you for your willingness to sponsor!<br>
<br>
To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl user who, in retirement, wanted to give something back to the Tcl community. Jim Tcl's successful use of this syntax for years demonstrates that the concept is viable.<br>
<br>
Regarding the telco: I attempted to join previously but was unsuccessful with the setup. I won't be able to participate on Monday, but I'm available via email for any questions or clarifications that arise from the discussion.<br>
<br>
I don't currently have write access to either the Tcl Fossil repository or the TIP repository, so I'm unable to make changes directly. At nearly 80 years old, I'm not comfortable learning new version control systems on my own. If the TIP moves forward, I'd
 need guidance and assistance with the Fossil workflow, or perhaps someone from the core team who shares our interest in this TIP could handle the integration based on my GitHub prototype.<br>
<br>
I'm currently developing a comprehensive test suite in standard tcltest format, with particular focus on edge cases.<br>
<br>
Looking forward to hearing how Monday's discussion goes!<br>
<br>
Best regards,<br>
Eric<br>
<br>
</div>
<div><br>
</div>
<div style="direction: ltr;">On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann &lt;<a class="OWAAutoLink" id="OWA2fbb6158-6c45-6109-517a-ee2f2e870a8d" href="mailto:har...@el...">har...@el...</a>&gt; wrote:</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div>Eric,<br>
sponsoring is no problem. The point is to get positive votes.<br>
This requires a positive discussion.<br>
You are the Author of Jim?<br>
Could you participate on the telco on Monday?<br>
<br>
Do you have write access to the tcl fossil? We would need the<br>
implementation there.<br>
<br>
Thanks for all,<br>
Harald<br>
<br>
Am 18.10.2025 um 22:58 schrieb EricT:<br>
&gt; Thank you for the positive feedback and for raising this in Monday's<br>
&gt; telco! I'm encouraged by your support.<br>
&gt;<br>
&gt; Regarding $(a) - you're right that reading an empty array element with a<br>
&gt; variable index is a valid construct. However, this is explicitly<br>
&gt; addressed in the TIP and the repository README. The workarounds are<br>
&gt; straightforward:<br>
&gt;<br>
&gt;&nbsp; &nbsp; ${(a)} &nbsp; &nbsp; &nbsp; &nbsp;# Braced form<br>
&gt;&nbsp; &nbsp; [set (a)] &nbsp; &nbsp; # Command substitution<br>
&gt;<br>
&gt; Both still work. In fact, code using $(varname) could be proactively<br>
&gt; modified to use ${(varname)} to indicate the clear intent of an empty<br>
&gt; array reference, which improves readability. The security, performance,<br>
&gt; and usability benefits of $(...) seemed to justify this trade-off for<br>
&gt; Tcl 9.x where some incompatibilities are expected.<br>
&gt;<br>
&gt; Given your interest in the feature, would you be willing to consider<br>
&gt; sponsoring TIP 672? The implementation is working and minimal (~100<br>
&gt; lines across two files), with the main open question being the preferred<br>
&gt; approach for tracking synthetic strings for cleanup. Your guidance on<br>
&gt; that architectural decision would be particularly valuable.<br>
&gt;<br>
&gt; The prototype repository with full implementation and examples is here:<br>
&gt;<br>
&gt; <a data-auth="NotApplicable" class="OWAAutoLink" id="OWAdaeb721a-2f2d-fd46-b16d-f7f9fa85487c" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$">
https://github.com/rocketship88/tcl-tip-672-prototype [github.com]</a>&nbsp;&lt;https://<br>
&gt; <a data-auth="NotApplicable" class="OWAAutoLink" id="OWA1c08f87f-3e1b-7345-47d1-f83e958ed390" href="https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$">
github.com/rocketship88/tcl-tip-672-prototype [github.com]</a>&gt;<br>
&gt;<br>
&gt; Looking forward to the results of the discussion on Monday! I won't be<br>
&gt; able to join the telco discussion, but I'm available via email for any<br>
&gt; questions or clarifications that arise.<br>
&gt;<br>
&gt;<br>
&gt; On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann<br>
&gt; &lt;<a class="OWAAutoLink" id="OWAd5fa5ee4-6688-a096-b39b-58044e2e7260" href="mailto:har...@el...">har...@el...</a>&nbsp;&lt;mailto:<a class="OWAAutoLink" id="OWAf2861fb4-1b96-a647-8bf1-afd401700057" href="mailto:har...@el...">har...@el...</a>&gt;&gt;
 wrote:<br>
&gt;<br>
&gt;&nbsp; &nbsp; &nbsp;Am 17.10.2025 um 23:22 schrieb EricT:<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Hello Tcl Core Team,<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; I have developed a working prototype implementation of TIP 672,<br>
&gt;&nbsp; &nbsp; &nbsp;which<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; adds the $(expression) syntax as a more intuitive alternative to<br>
&gt;&nbsp; &nbsp; &nbsp;[expr<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; {expression}].<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Repository: <a data-auth="NotApplicable" class="OWAAutoLink" id="OWAce957dfa-015b-f49e-7f83-9d4c46409d16" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$">
https://github.com/rocketship88/tcl-tip-672-prototype [github.com]</a><br>
&gt;&nbsp; &nbsp; &nbsp;&lt;<a data-auth="NotApplicable" class="OWAAutoLink" id="OWA94372cbc-677c-140b-b1b9-19e6a24a6c78" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$">https://github.com/rocketship88/tcl-tip-672-prototype
 [github.com]</a>&gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; &lt;<a data-auth="NotApplicable" class="OWAAutoLink" id="OWA40bf9571-1dc9-0b4c-1210-7d004ffe86fc" href="https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$">https://github.com/rocketship88/tcl-tip-672-prototype
 [github.com]</a>&nbsp;&lt;https://<br>
&gt;&nbsp; &nbsp; &nbsp;<a data-auth="NotApplicable" class="OWAAutoLink" id="OWAbd5aac6c-e012-89e6-4559-05a1150d33b2" href="https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$">github.com/rocketship88/tcl-tip-672-prototype
 [github.com]</a>&gt;&gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; The implementation is minimal, modifying only two files<br>
&gt;&nbsp; &nbsp; &nbsp;(tclParse.c and<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; tclNamesp.c) with approximately 100 lines of changes. The key<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; modification converts the existing two-way branch in<br>
&gt;&nbsp; &nbsp; &nbsp;Tcl_ParseVarName to<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; a three-way branch, with the new path handling $(...) by creating a<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; synthetic [expr {...}] command string.<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Key Accomplishments:<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Full bytecode compilation: The synthetic string approach integrates<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; seamlessly with the existing compiler, producing identical optimized<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; bytecode as [expr {...}]. The disassembler output (shown in the<br>
&gt;&nbsp; &nbsp; &nbsp;README)<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; demonstrates efficient variable loading with no runtime parsing<br>
&gt;&nbsp; &nbsp; &nbsp;overhead.<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Proven approach: Jim Tcl has used this syntax successfully for years<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Comprehensive testing: Works correctly with string interpolation,<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; variable scoping, error handling, and interactive mode<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Known Limitations:<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Memory leak: The synthetic string is allocated but not tracked for<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; cleanup in Tcl_FreeParse. This requires core team guidance on the<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; preferred solution (modify Tcl_Parse structure vs. thread-local<br>
&gt;&nbsp; &nbsp; &nbsp;tracking).<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Error messages: Currently show the synthetic command rather than the<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; original $(...) syntax, though this is arguably helpful for<br>
&gt;&nbsp; &nbsp; &nbsp;debugging.<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Questions for the Team:<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; What is the preferred approach for tracking synthetic strings for<br>
&gt;&nbsp; &nbsp; &nbsp;cleanup?<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Is this prototype architecture acceptable for Tcl 9.x?<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Are there concerns with the synthetic string approach that I<br>
&gt;&nbsp; &nbsp; &nbsp;should address?<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; The complete implementation with side-by-side diffs is available<br>
&gt;&nbsp; &nbsp; &nbsp;in the<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; repository. I'm happy to refine the code based on your feedback and<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; would appreciate any guidance on moving this forward.<br>
&gt;&nbsp; &nbsp; &nbsp; &gt;<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Best regards,<br>
&gt;&nbsp; &nbsp; &nbsp; &gt; Eric<br>
&gt;&nbsp; &nbsp; &nbsp;Eric,<br>
&gt;&nbsp; &nbsp; &nbsp;great proposal, thank you !<br>
&gt;<br>
&gt;&nbsp; &nbsp; &nbsp;Perhaps, we may discuss this on Monday in the biweekly telco.<br>
&gt;&nbsp; &nbsp; &nbsp;I am also excited and in favor to this.<br>
&gt;&nbsp; &nbsp; &nbsp;Nevertheless, "$(a)" is to my knowledge a quite common syntax for<br>
&gt;&nbsp; &nbsp; &nbsp;arrays. We have already killed less disruptive proposals (see optional<br>
&gt;&nbsp; &nbsp; &nbsp;"- args") by endless discussions and getting nowhere.<br>
&gt;&nbsp; &nbsp; &nbsp;Hope, this will be fruitful.<br>
&gt;<br>
&gt;&nbsp; &nbsp; &nbsp;In addition, I would like to add the Tk test reform by the other<br>
&gt;&nbsp; &nbsp; &nbsp;Eric to<br>
&gt;&nbsp; &nbsp; &nbsp;the biweekly topics.<br>
&gt;&nbsp; &nbsp; &nbsp;Here is a revised agenda proposal proposal:<br>
&gt;<br>
&gt;&nbsp; &nbsp; &nbsp;Top 1) Release calender (TIP 713)<br>
&gt;&nbsp; &nbsp; &nbsp;- 9.0.3: October (2 weeks left)<br>
&gt;&nbsp; &nbsp; &nbsp;- 9.1a1: November (6 weeks left)<br>
&gt;&nbsp; &nbsp; &nbsp;Top 2) TIP 734 nested mutex (go or not)<br>
&gt;&nbsp; &nbsp; &nbsp;Top 3) TIP 733: accessability (test status)<br>
&gt;&nbsp; &nbsp; &nbsp;Top 4) TIP 732: TCL library path (discussion)<br>
&gt;&nbsp; &nbsp; &nbsp;Top 5) TIP 731: use C enums (no brainer?)<br>
&gt;&nbsp; &nbsp; &nbsp;Top 6) TIP 720: new bytecodes (final, great! Any issues?)<br>
&gt;&nbsp; &nbsp; &nbsp;Top 7) TIP 721: Tcl_AttemptGetString<br>
&gt;&nbsp; &nbsp; &nbsp;Top 8) TIP 715: supported build systems<br>
&gt;&nbsp; &nbsp; &nbsp;Top 9) $($a+$b) syntax for expressions<br>
&gt;&nbsp; &nbsp; &nbsp;Top 10) Tk test reform by Eric (Thanks !)<br>
&gt;&nbsp; &nbsp; &nbsp;Top 11) Tcl depot and awthemes ?<br>
&gt;&nbsp; &nbsp; &nbsp;Top 12) AOB<br>
&gt;&nbsp; &nbsp; &nbsp;Top 13) Next meeting:<br>
&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;3rd of November 12:00 UTC.<br>
&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Daytime saving time ends 2nd of November in US, 26th of<br>
&gt;&nbsp; &nbsp; &nbsp;October in<br>
&gt;&nbsp; &nbsp; &nbsp;Europe.<br>
&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?<br>
&gt;<br>
&gt;&nbsp; &nbsp; &nbsp;Take care,<br>
&gt;&nbsp; &nbsp; &nbsp;Harald<br>
_______________________________________________<br>
Tcl-Core mailing list<br>
<a class="OWAAutoLink" id="OWAf1cd5ec3-5d97-fbde-0c52-b7c698f69775" href="mailto:Tcl...@li...">Tcl...@li...</a><br>
<a data-auth="NotApplicable" class="OWAAutoLink" id="OWAa4f4fc9a-55e5-a33e-f0a7-08748655b707" href="https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$">https://lists.sourceforge.net/lists/listinfo/tcl-core
 [lists.sourceforge.net]</a></div>
</blockquote>
</blockquote>
<div>_______________________________________________<br>
Tcl-Core mailing list<br>
<a class="OWAAutoLink" id="OWAf7715aa5-657f-5210-174d-19047f1ff76e" href="mailto:Tcl...@li...">Tcl...@li...</a><br>
<a data-auth="NotApplicable" class="OWAAutoLink" id="OWA379eb571-ba61-7a7c-a12f-00064b6d4c0d" href="https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$">https://lists.sourceforge.net/lists/listinfo/tcl-core
 [lists.sourceforge.net]</a></div>
</blockquote>
<div><br>
</div>
<div>_______________________________________________<br>
Tcl-Core mailing list<br>
<a class="OWAAutoLink" id="OWA03fcfbd3-f104-e894-3393-012223471655" href="mailto:Tcl...@li...">Tcl...@li...</a><br>
<a data-auth="NotApplicable" class="OWAAutoLink" id="OWA370068aa-2027-2f72-9d23-2e57871abfcd" href="https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$">https://lists.sourceforge.net/lists/listinfo/tcl-core
 [lists.sourceforge.net]</a></div>
</blockquote>


<span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span>Tcl...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/tcl-core</span><br></div></blockquote></body></html>

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

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

Since I needed to fix the indentation (@jan, can you verify I got it
cleaned up) I went ahead and added the $((...)) as a mode 3.

When downloaded, it is set to mode 1 $(...) and that will test against the
included .test file and with mode 1 there will be one error, where it does
a simple empty array $(index) compatibility test and should fail as
expected.

When the mode is set to 2 or 3 $=(...) and $((...)) (line 120) and rebuilt,
then that error should not occur. The test file otherwise works the same
for mode 1 and mode 3.

However, to change the test file for mode 2 $=(...) one can use a global
replace of $(( to $=(( which is easier than removing one of the trailing
))'s that all the tests now use. This is because $=((...)) will work as
well as $=(...) it just treats the second set of inside ()'s as
mathematical ()'s and expr is fine with that.

Everything is at the usual site. If you try to do a diff on the next to
last commit that fixes the indentation as well as adds the $((...)), you
will want to change the gear wheel setting to hide whitespace, then you can
see the fairly minimal changes needed to add the $((...)) mode.

Thanks all,
Eric



On Thu, Oct 23, 2025 at 5:06 PM EricT <tw...@gm...> wrote:

> Phillip:
>
> Yes, as I sent you with more detail, this appears to be a bug. I can't
> imagine this could have foreseen our discussions and deliberately made
> $((...) output an error so we could use it for our own purposes.
>
> And if it's a bug and gets fixed, that would restore the 8.6 behavior and
> lead to a small but non-zero chance of a conflict. If there are other cases
> this same code change affects, there could be tickets which eventually fix
> the bug. We wouldn't want to base a decision on a bug remaining in the
> system forever.
>
> Eric
>
>
>
>
> On Thu, Oct 23, 2025 at 3:11 PM Phillip Brooks <phi...@um...> wrote:
>
>> I believe that
>>
>> > $((...)) - Also conflicts with empty arrays when index starts with (
>> like $((index)
>>
>> is not actually true.  With 9.0:
>>
>> $ /usr/local/bin/tclsh9.0
>>
>> % array set {} { (index) 99 }
>>
>> % puts $((index))
>>
>> invalid character in array index
>>
>> %
>>
>> or
>>
>> % /usr/local/bin/tclsh9.0
>>
>> % array set {} { (index 99 }
>>
>> % puts $((index)
>>
>> invalid character in array index
>>
>>
>> The '(' character that is part of the index must be escaped:
>>
>>
>> In the first case:
>>
>>
>> % puts $(\(index\))
>>
>> 99
>>
>>
>> or in the second case:
>>
>>
>> % puts $(\(index)
>>
>> 99
>>
>> %
>>
>> I think that there are still no identified conflicts with Tcl 9.0 and $((
>> expr )).  If I am mistaken, please post the breaking example code.
>>
>> Eric, I believe that you identified some parsing changes that happened
>> between 8.6 and 9.0 in regard to the presence of '(' and ')' in that regard.
>>
>> Phil
>>
>> On Thu, Oct 23, 2025 at 1:16 PM EricT <tw...@gm...> wrote:
>>
>>> Hi Kevin:
>>>
>>> Yes, the main breakage issue is the empty array case that's been
>>> discussed extensively here.
>>>
>>> When I wrote the TIP, it was originally targeted for 9.0 when breaking
>>> changes were permitted. It got bumped to 9.1, though I didn't change that
>>> myself.
>>>
>>> The real innovation here is the parser injection point that enables
>>> multiple syntaxes with minimal code changes. Three are being considered:
>>>
>>> $(...) - Cleanest syntax, but conflicts with empty array shortcut
>>> $(index)
>>> $=(...) - Virtually no conflicts - literal $=( is extremely rare without
>>> escaping \$=(
>>> $((...)) - Also conflicts with empty arrays when index starts with (
>>> like $((index)
>>>
>>> My prototype already implements the first two; someone else is working
>>> on the third. The extremely minor conflicts in options 2 and 3 are unlikely
>>> to affect real code.
>>>
>>> The choice is up to the core team. Having a working C implementation
>>> helps inform that decision. I hope to earn your yes vote, and I'm happy to
>>> answer any questions.
>>>
>>>
>>> On Thu, Oct 23, 2025 at 4:42 AM Kevin Walzer <kw...@co...> wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> On 10/22/25 10:12 PM, EricT wrote:
>>>> > This works both before and after the feature if adopted, so code can
>>>> > be migrated proactively. The pragma approach would help identify all
>>>> > $() uses that need updating.
>>>>
>>>> So you appear to be confirming that changing the [expr] syntax *will*
>>>> have side effects that require changes in other code.
>>>>
>>>> I'm generally agnostic about language changes to Tcl, and I don't have
>>>> a
>>>> strong opinion about the various alternatives presented in this
>>>> discussion. I'll leave that to the experts.
>>>>
>>>> However, the cranky, "don't make it worse" developer in me is prompted
>>>> to ask: Why should other parts of my code have to change to accommodate
>>>> this language update that I may not even use?
>>>>
>>>> If the answer is, "We are now in Tcl 9, and breaking changes are OK,"
>>>> my
>>>> response is, "Sure, that was true for 9.0. The breaking changes were
>>>> planned and long communicated."
>>>>
>>>> In other words -  the issue is not really variable substitution in
>>>> itself, but whether the window for breaking changes is still open. I
>>>> thought we were done with that and the window is now closed.
>>>>
>>>> That's more of a question for the TCT as a whole, and I don't have the
>>>> answer. I am inclined to vote against a TIP with breaking changes
>>>> because I don't like breaking changes, but I am open to being persuaded
>>>> on the larger topic - that we are not done making those kinds of
>>>> changes
>>>> to the language and it's OK.
>>>>
>>>> --Kevin
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>

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

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

Phillip:

Yes, as I sent you with more detail, this appears to be a bug. I can't
imagine this could have foreseen our discussions and deliberately made
$((...) output an error so we could use it for our own purposes.

And if it's a bug and gets fixed, that would restore the 8.6 behavior and
lead to a small but non-zero chance of a conflict. If there are other cases
this same code change affects, there could be tickets which eventually fix
the bug. We wouldn't want to base a decision on a bug remaining in the
system forever.

Eric




On Thu, Oct 23, 2025 at 3:11 PM Phillip Brooks <phi...@um...> wrote:

> I believe that
>
> > $((...)) - Also conflicts with empty arrays when index starts with (
> like $((index)
>
> is not actually true.  With 9.0:
>
> $ /usr/local/bin/tclsh9.0
>
> % array set {} { (index) 99 }
>
> % puts $((index))
>
> invalid character in array index
>
> %
>
> or
>
> % /usr/local/bin/tclsh9.0
>
> % array set {} { (index 99 }
>
> % puts $((index)
>
> invalid character in array index
>
>
> The '(' character that is part of the index must be escaped:
>
>
> In the first case:
>
>
> % puts $(\(index\))
>
> 99
>
>
> or in the second case:
>
>
> % puts $(\(index)
>
> 99
>
> %
>
> I think that there are still no identified conflicts with Tcl 9.0 and $((
> expr )).  If I am mistaken, please post the breaking example code.
>
> Eric, I believe that you identified some parsing changes that happened
> between 8.6 and 9.0 in regard to the presence of '(' and ')' in that regard.
>
> Phil
>
> On Thu, Oct 23, 2025 at 1:16 PM EricT <tw...@gm...> wrote:
>
>> Hi Kevin:
>>
>> Yes, the main breakage issue is the empty array case that's been
>> discussed extensively here.
>>
>> When I wrote the TIP, it was originally targeted for 9.0 when breaking
>> changes were permitted. It got bumped to 9.1, though I didn't change that
>> myself.
>>
>> The real innovation here is the parser injection point that enables
>> multiple syntaxes with minimal code changes. Three are being considered:
>>
>> $(...) - Cleanest syntax, but conflicts with empty array shortcut $(index)
>> $=(...) - Virtually no conflicts - literal $=( is extremely rare without
>> escaping \$=(
>> $((...)) - Also conflicts with empty arrays when index starts with ( like
>> $((index)
>>
>> My prototype already implements the first two; someone else is working on
>> the third. The extremely minor conflicts in options 2 and 3 are unlikely to
>> affect real code.
>>
>> The choice is up to the core team. Having a working C implementation
>> helps inform that decision. I hope to earn your yes vote, and I'm happy to
>> answer any questions.
>>
>>
>> On Thu, Oct 23, 2025 at 4:42 AM Kevin Walzer <kw...@co...> wrote:
>>
>>> Hi Eric,
>>>
>>> On 10/22/25 10:12 PM, EricT wrote:
>>> > This works both before and after the feature if adopted, so code can
>>> > be migrated proactively. The pragma approach would help identify all
>>> > $() uses that need updating.
>>>
>>> So you appear to be confirming that changing the [expr] syntax *will*
>>> have side effects that require changes in other code.
>>>
>>> I'm generally agnostic about language changes to Tcl, and I don't have a
>>> strong opinion about the various alternatives presented in this
>>> discussion. I'll leave that to the experts.
>>>
>>> However, the cranky, "don't make it worse" developer in me is prompted
>>> to ask: Why should other parts of my code have to change to accommodate
>>> this language update that I may not even use?
>>>
>>> If the answer is, "We are now in Tcl 9, and breaking changes are OK," my
>>> response is, "Sure, that was true for 9.0. The breaking changes were
>>> planned and long communicated."
>>>
>>> In other words -  the issue is not really variable substitution in
>>> itself, but whether the window for breaking changes is still open. I
>>> thought we were done with that and the window is now closed.
>>>
>>> That's more of a question for the TCT as a whole, and I don't have the
>>> answer. I am inclined to vote against a TIP with breaking changes
>>> because I don't like breaking changes, but I am open to being persuaded
>>> on the larger topic - that we are not done making those kinds of changes
>>> to the language and it's OK.
>>>
>>> --Kevin
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>

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

[Phillip B. <phi...@um...>]

I believe that

> $((...)) - Also conflicts with empty arrays when index starts with ( like
$((index)

is not actually true.  With 9.0:

$ /usr/local/bin/tclsh9.0

% array set {} { (index) 99 }

% puts $((index))

invalid character in array index

%

or

% /usr/local/bin/tclsh9.0

% array set {} { (index 99 }

% puts $((index)

invalid character in array index


The '(' character that is part of the index must be escaped:


In the first case:


% puts $(\(index\))

99


or in the second case:


% puts $(\(index)

99

%

I think that there are still no identified conflicts with Tcl 9.0 and $((
expr )).  If I am mistaken, please post the breaking example code.

Eric, I believe that you identified some parsing changes that happened
between 8.6 and 9.0 in regard to the presence of '(' and ')' in that regard.

Phil

On Thu, Oct 23, 2025 at 1:16 PM EricT <tw...@gm...> wrote:

> Hi Kevin:
>
> Yes, the main breakage issue is the empty array case that's been discussed
> extensively here.
>
> When I wrote the TIP, it was originally targeted for 9.0 when breaking
> changes were permitted. It got bumped to 9.1, though I didn't change that
> myself.
>
> The real innovation here is the parser injection point that enables
> multiple syntaxes with minimal code changes. Three are being considered:
>
> $(...) - Cleanest syntax, but conflicts with empty array shortcut $(index)
> $=(...) - Virtually no conflicts - literal $=( is extremely rare without
> escaping \$=(
> $((...)) - Also conflicts with empty arrays when index starts with ( like
> $((index)
>
> My prototype already implements the first two; someone else is working on
> the third. The extremely minor conflicts in options 2 and 3 are unlikely to
> affect real code.
>
> The choice is up to the core team. Having a working C implementation helps
> inform that decision. I hope to earn your yes vote, and I'm happy to answer
> any questions.
>
>
> On Thu, Oct 23, 2025 at 4:42 AM Kevin Walzer <kw...@co...> wrote:
>
>> Hi Eric,
>>
>> On 10/22/25 10:12 PM, EricT wrote:
>> > This works both before and after the feature if adopted, so code can
>> > be migrated proactively. The pragma approach would help identify all
>> > $() uses that need updating.
>>
>> So you appear to be confirming that changing the [expr] syntax *will*
>> have side effects that require changes in other code.
>>
>> I'm generally agnostic about language changes to Tcl, and I don't have a
>> strong opinion about the various alternatives presented in this
>> discussion. I'll leave that to the experts.
>>
>> However, the cranky, "don't make it worse" developer in me is prompted
>> to ask: Why should other parts of my code have to change to accommodate
>> this language update that I may not even use?
>>
>> If the answer is, "We are now in Tcl 9, and breaking changes are OK," my
>> response is, "Sure, that was true for 9.0. The breaking changes were
>> planned and long communicated."
>>
>> In other words -  the issue is not really variable substitution in
>> itself, but whether the window for breaking changes is still open. I
>> thought we were done with that and the window is now closed.
>>
>> That's more of a question for the TCT as a whole, and I don't have the
>> answer. I am inclined to vote against a TIP with breaking changes
>> because I don't like breaking changes, but I am open to being persuaded
>> on the larger topic - that we are not done making those kinds of changes
>> to the language and it's OK.
>>
>> --Kevin
>>
>>
>>
>> _______________________________________________
>> 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
>

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

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

Hi Kevin:

Yes, the main breakage issue is the empty array case that's been discussed
extensively here.

When I wrote the TIP, it was originally targeted for 9.0 when breaking
changes were permitted. It got bumped to 9.1, though I didn't change that
myself.

The real innovation here is the parser injection point that enables
multiple syntaxes with minimal code changes. Three are being considered:

$(...) - Cleanest syntax, but conflicts with empty array shortcut $(index)
$=(...) - Virtually no conflicts - literal $=( is extremely rare without
escaping \$=(
$((...)) - Also conflicts with empty arrays when index starts with ( like
$((index)

My prototype already implements the first two; someone else is working on
the third. The extremely minor conflicts in options 2 and 3 are unlikely to
affect real code.

The choice is up to the core team. Having a working C implementation helps
inform that decision. I hope to earn your yes vote, and I'm happy to answer
any questions.


On Thu, Oct 23, 2025 at 4:42 AM Kevin Walzer <kw...@co...> wrote:

> Hi Eric,
>
> On 10/22/25 10:12 PM, EricT wrote:
> > This works both before and after the feature if adopted, so code can
> > be migrated proactively. The pragma approach would help identify all
> > $() uses that need updating.
>
> So you appear to be confirming that changing the [expr] syntax *will*
> have side effects that require changes in other code.
>
> I'm generally agnostic about language changes to Tcl, and I don't have a
> strong opinion about the various alternatives presented in this
> discussion. I'll leave that to the experts.
>
> However, the cranky, "don't make it worse" developer in me is prompted
> to ask: Why should other parts of my code have to change to accommodate
> this language update that I may not even use?
>
> If the answer is, "We are now in Tcl 9, and breaking changes are OK," my
> response is, "Sure, that was true for 9.0. The breaking changes were
> planned and long communicated."
>
> In other words -  the issue is not really variable substitution in
> itself, but whether the window for breaking changes is still open. I
> thought we were done with that and the window is now closed.
>
> That's more of a question for the TCT as a whole, and I don't have the
> answer. I am inclined to vote against a TIP with breaking changes
> because I don't like breaking changes, but I am open to being persuaded
> on the larger topic - that we are not done making those kinds of changes
> to the language and it's OK.
>
> --Kevin
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

Actually, the only efficiency gain is with constant folding, the compiler
just can't combine the two:

% tcl::unsupported::disassemble script {set a $(1 + ([expr {2-1}]))}
ByteCode 0x23090eb7460, refCt 1, epoch 22, interp 0x230898e0830 (epoch 22)
  Source "set a $(1 + ([expr {2-1}]))"
  Cmds 3, src 27, inst 18, litObjs 3, aux 0, stkDepth 3, code/src 0.00
  Commands 3:
      1: pc 0-16, src 0-26        2: pc 5-15, src 6529-6553
      3: pc 10-14, src 6541-6550
  Command 1: "set a $(1 + ([expr {2-1}]))"
    (0) push 0 # "a"
  Command 2: "expr {1 + ([expr {2-1}])}..."
    (5) push 1 # "1"
  Command 3: "expr {2-1}..."
    (10) push 2 # "1"
    (15) add
    (16) storeStk
    (17) done

% tcl::unsupported::disassemble script {set a $(1 + (2-1))}
ByteCode 0x23090eb6c60, refCt 1, epoch 22, interp 0x230898e0830 (epoch 22)
  Source "set a $(1 + (2-1))"
  Cmds 2, src 18, inst 12, litObjs 2, aux 0, stkDepth 2, code/src 0.00
  Commands 2:
      1: pc 0-10, src 0-17        2: pc 5-9, src 3334001-3334016
  Command 1: "set a $(1 + (2-1))"
    (0) push 0 # "a"
  Command 2: "expr {1 + (2-1)}..."
    (5) push 1 # "2"
    (10) storeStk
    (11) done

E


On Thu, Oct 23, 2025 at 11:17 AM EricT <tw...@gm...> wrote:

> Jan:
>
> You mentioned the non-standard indenting - that's a tab/space mixing
> issue. I have ongoing trouble with Tcl's tab size 8 + indent 4 standard.
>
> The problem: with 8-char tabs, odd indentation levels require mixing tabs
> and spaces, which breaks when editors differ. Adding an outer if
> statement can mess up the spacing.
>
> I'd recommend Tcl adopt tab size 4 + indent 4, which eliminates the issue
> - whether your editor inserts spaces or tabs, it looks the same.
>
> For my sections: would converting to spaces-only work for the community? I
> hesitate to change the entire file.
> On testing:
>
> I converted my test file from $() to $(()) syntax and ran it against mode
> 1 - 82 of 84 passed. The two failures were empty expression tests expecting
> different error messages (become sub-expressions). I fixed them with a
> flexible pattern:
>
> string match "*empty*expression*" $msg
>
> Now they work with either syntax.  This is something to keep in mind if
> $(()) were chosen, and years later relaxed to just $() after the $(index)
> empty array was deprecated.
>
> Regarding nested $():
>
> $(... $(...)...) fails because expr (or the compiler) rejects the nested $
> in the expression.
>
> But $(... [expr {...}]...) works fine. There's no reason to nest anyway -
> removing the inner $ gives the same result more efficiently.
>
> Eric
>
>
> On Thu, Oct 23, 2025 at 8:18 AM da Silva, Peter J <
> pet...@fl...> wrote:
>
>> 5 is basically equivalent to 1, it’s just a convention.
>>
>>
>>
>> *From: *Donal Fellows <don...@ma...>
>> *Date: *Thursday, October 23, 2025 at 06:15
>> *To: *Florent Merlet <flo...@gm...>,
>> tcl...@li... <tcl...@li...>
>> *Subject: *Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready
>> for Sponsorship
>>
>> ​ Conclusion : There is no real choice ​ That's an incorrect conclusion.
>> At least one of the priors you use in reaching it is invalid. The core of
>> the proposal is that the sequence $( start a new syntax category (with what
>> follows being an expression
>>
>> ​
>>
>> Conclusion : There is no real choice
>>
>> ​
>>
>> That's an incorrect conclusion. At least one of the priors you use in
>> reaching it is invalid.
>>
>>
>>
>> The core of the proposal is that the sequence *$(* start a *new* syntax
>> category (with what follows being an expression to the point where there's
>> a *matching *parenthesis using an appropriate recursive matching
>> algorithm, with a similar model to how command substitutions work). This
>> new syntactic entity will be called (almost certainly) an *expression
>> substitution*. That it starts with *$* is good; existing code that
>> inserts backslashes before dollar signs to make things *subst*-safe will
>> not be surprised; normally we'd recommend such approaches instead now
>> switch to using *regsub -command*, due to the way *subst *works, but
>> that's a longer-term change-over.
>>
>>
>>
>> That the C code inside the Tcl parsing engine will need to change to
>> accommodate a new syntax category isn't a deep insight. Of course it will
>> need to change. Such change is what is being proposed!
>>
>>
>>
>> Right now, the real discussion is what the sequence of literal characters
>> in a Tcl script to introduce the new syntax should be. The options in play
>> are:
>>
>>
>>
>>    1. Do nothing. Stick with *[expr {*expression...*}]*. This option is *always
>>    open* to us.
>>
>>
>>    2. Use *$(*expression...*)*
>>
>>
>>    3. Use *$((*expression...*))*
>>
>>
>>    4. Use *[={*expression...*}]*
>>
>>
>>    5. Use *[=* expression...*]*
>>
>>
>>    6. Use *[(*expression...*)]*
>>
>>
>>    7. Use something else (I've probably missed an option or two from
>>    this painting of the bikeshed)
>>
>>
>>
>> Of the options above, 2 has *real *compatibility issues (i.e., we *know *it
>> will clash with existing code in Tcllib) and 5 probably has semantic issues
>> (because it was proposed as an actual command; anything that introduces
>> uncontrolled double substitution is a no-no at this point). Option 3 has
>> been assessed for practical compatibility, and should be fine (except for a
>> few places in JimTcl, written by someone *already in this conversation*).
>> Option 4 manages to be ugly, but is probably OK in terms of amount of
>> in-the-wild usage. Option 6 hasn't been assessed yet.
>>
>>
>>
>> For all options that introduce a new syntactic substitution class, a
>> change to *subst *is needed to work with it (Jan's outlined this
>> adequately) and there should be consideration whether the other
>> mini-languages inside Tcl should change (we have several).
>>
>>
>>
>> Donal.
>>
>>
>> ------------------------------
>>
>> *From:* Florent Merlet <flo...@gm...>
>> *Sent:* Thursday, October 23, 2025 09:32
>> *To:* tcl...@li... <tcl...@li...>
>> *Subject:* Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready
>> for Sponsorship
>>
>>
>>
>> Hello Jan, So we can admit that the implementation is not ready. In fact,
>> expression is modelised like a variable and it can't nest. Fondamentally,
>> the problem is that the « $ » sign allways has been related to the concept
>> of variable, whereas
>>
>> Hello Jan,
>>
>> So we can admit that the implementation is not ready.
>>
>> In fact, expression is modelised like a variable and it can't nest.
>>
>> Fondamentally, the problem is that the « $ » sign allways has been
>> related to the concept of variable, whereas an expression is related to the
>> concept of command.
>>
>> « variables » have caracteristics that differ from the one of « commands
>> » .
>>
>> « commands » can nest, whereas « variables » don't.
>>
>> These distinct caracteristics were translated directly in the programm
>> flow, because, at a certain degree, there must be an analogy between the
>> flow of the programm and the caracteristics of the concept.
>>
>> In Parse_token, the « $ » branch doesn't need to handle any nesting. Only
>> the « [ » branch need to handle nesting.
>>
>> In fact, the proposal falls in the bad branch of « parse_Token », the «
>> variable » branch, which tests for the presence of a « $ » char.
>>
>> The good branch for such an implementation is the « command »
>> branch, that test for the presence of a « [ » char, because a command can
>> nest.
>>
>> Conclusion : There is no real choice : the expr shorthand proposal must
>> begin with a « [ », if not, the price paid by the source code will be too
>> big, because of the radical difference between the « variable » and «
>> command » concepts. At the end, you could have to recreate the flow for
>> commands in the flow for variables.
>>
>> That's why, instead, I proposed this shorthand : « [( ... )] »
>>
>> It will be detected in the command branch of parse token, so that :
>>
>> 1. subst -noc can inhibit it : no need to change anything in the actual
>> logic
>>
>> (an open question remains : how -nocommands et -noexpression flags will
>> interfer, we may want -nocommand -withexpression after all)
>>
>> 2. We just have to check
>>
>>  } else if (*src == '[' && src[1] =='(') {
>>
>>     if (noSubstExpr) {
>>         tokenPtr->type = TCL_TOKEN_TEXT;
>>         tokenPtr->size = 2;
>>         parsePtr->numTokens++;
>>         src+=2;
>>         numBytes-=2;
>>         continue;
>>         }
>>
>>     Tcl_Parse *nestedPtr;   src+=2;  numBytes-=2;
>>
>>     int length = tclParseExpression(src); // to be created :
>>
>>    opnode *opnode
>>
>>    nestedPtr = (Tcl_Parse *)TclStackAlloc(parsePtr->interp,
>> sizeof(Tcl_Parse));
>>
>>    if (Tcl_ParseExpr(interp, src, -1, nestedPtr) != TCL_OK) {...}
>>
>>    ...etc
>>
>> I think, globally, this would be a simpler change, since we are not mixing carrots and potatoes.
>>
>> Honnestly, is the following code so bad visualy ?
>>
>> % set script [subst -noc {
>>
>>     set x [(1+1)]
>>
>> }]
>>
>> % set a 2
>>
>> % set script [subst -nov {
>>
>>    set x [(2+$a)]
>>
>> }]
>>
>> % set x [( 3 + [(3+3)] )]
>>
>> % set x [expr {4+[(4+4)]}]
>>
>>
>>
>>
>>
>>
>>
>> Le 23/10/2025 à 09:43, Jan Nijtmans a écrit :
>>
>> Op do 23 okt 2025 om 07:56 schreef Florent Merlet:
>>
>> What are the results of these commands:
>>
>> % set script [subst -noc {
>>
>>     set x $(1+1)
>>
>> }]
>>
>>
>>
>>     set x 2
>>
>>
>>
>> % set a 2
>>
>> 2
>>
>> % set script [subst -nov {
>>
>>    set x $(2+$a)
>>
>> }]
>>
>>
>>
>>    set x 4
>>
>>
>>
>> % set x $(3+$(3+3))
>>
>> invalid character "$"
>>
>> in expression "3+$(3+3)"
>>
>> % set x [expr {4+$(4+4)}]
>>
>> invalid character "$"
>>
>> in expression "4+$(4+4)"
>>
>> %
>>
>>
>>
>> I think all of those are expected. The first answer does
>>
>> "expr" substitution, the option "-noc" doesn't change
>>
>> anything on that (-noexpr would!). The second one
>>
>> also does expr substitution, the variable $a is handled
>>
>> by the expr handling itself. So that's expected too.
>>
>>
>>
>> The latter 2 are also as I expect, since $( substitution
>>
>> should not be done within expressions itself.
>>
>>
>>
>> This test is done with the version in the fossil "tip-672"
>>
>> branch. This branch is based on an earlier version from Eric.
>>
>> (@eric, could you base later changes on this version?
>>
>> you use a non-standard indenting, that makes merging
>>
>> in later versions rather cumbersome)
>>
>>
>>
>> One thing already discussed was to adapt the "subst"
>>
>> command for the new substitution. The tip-672 branch
>>
>> adds new -expr and -noexpr options, so the new proposed
>>
>> substitution can be switched on or off at will. I think
>>
>> that should be added to the TIP text.
>>
>>
>>
>> For now, I'll wait for the result of the discussion.
>>
>>
>>
>> Florent Merlet wrote:
>>
>> Is it to make people to go far away from Tcl ?
>>
>> Such accusations don't help anything in this
>>
>> discussion. That's all I'm going to say about it.
>>
>> Hope this helps,
>>
>>        Jan Nijtmans
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Tcl-Core mailing list
>>
>> Tcl...@li...
>>
>> https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net] <https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!G2apoGRhxYjjkcB234n_qe1j3E65OHgCeKrFVRNGPkptfDmsAOCfgWEx4K2_YpAcsWbWY_5Bm2XkftSqpPt9ZcYmA1AMGovG0wSuHcY$>
>>
>> --
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>

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

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

 Jan:

You mentioned the non-standard indenting - that's a tab/space mixing issue.
I have ongoing trouble with Tcl's tab size 8 + indent 4 standard.

The problem: with 8-char tabs, odd indentation levels require mixing tabs
and spaces, which breaks when editors differ. Adding an outer if
statement can mess up the spacing.

I'd recommend Tcl adopt tab size 4 + indent 4, which eliminates the issue -
whether your editor inserts spaces or tabs, it looks the same.

For my sections: would converting to spaces-only work for the community? I
hesitate to change the entire file.
On testing:

I converted my test file from $() to $(()) syntax and ran it against mode 1
- 82 of 84 passed. The two failures were empty expression tests expecting
different error messages (become sub-expressions). I fixed them with a
flexible pattern:

string match "*empty*expression*" $msg

Now they work with either syntax.  This is something to keep in mind if
$(()) were chosen, and years later relaxed to just $() after the $(index)
empty array was deprecated.

Regarding nested $():

$(... $(...)...) fails because expr (or the compiler) rejects the nested $
in the expression.

But $(... [expr {...}]...) works fine. There's no reason to nest anyway -
removing the inner $ gives the same result more efficiently.

Eric


On Thu, Oct 23, 2025 at 8:18 AM da Silva, Peter J <
pet...@fl...> wrote:

> 5 is basically equivalent to 1, it’s just a convention.
>
>
>
> *From: *Donal Fellows <don...@ma...>
> *Date: *Thursday, October 23, 2025 at 06:15
> *To: *Florent Merlet <flo...@gm...>,
> tcl...@li... <tcl...@li...>
> *Subject: *Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for
> Sponsorship
>
> ​ Conclusion : There is no real choice ​ That's an incorrect conclusion.
> At least one of the priors you use in reaching it is invalid. The core of
> the proposal is that the sequence $( start a new syntax category (with what
> follows being an expression
>
> ​
>
> Conclusion : There is no real choice
>
> ​
>
> That's an incorrect conclusion. At least one of the priors you use in
> reaching it is invalid.
>
>
>
> The core of the proposal is that the sequence *$(* start a *new* syntax
> category (with what follows being an expression to the point where there's
> a *matching *parenthesis using an appropriate recursive matching
> algorithm, with a similar model to how command substitutions work). This
> new syntactic entity will be called (almost certainly) an *expression
> substitution*. That it starts with *$* is good; existing code that
> inserts backslashes before dollar signs to make things *subst*-safe will
> not be surprised; normally we'd recommend such approaches instead now
> switch to using *regsub -command*, due to the way *subst *works, but
> that's a longer-term change-over.
>
>
>
> That the C code inside the Tcl parsing engine will need to change to
> accommodate a new syntax category isn't a deep insight. Of course it will
> need to change. Such change is what is being proposed!
>
>
>
> Right now, the real discussion is what the sequence of literal characters
> in a Tcl script to introduce the new syntax should be. The options in play
> are:
>
>
>
>    1. Do nothing. Stick with *[expr {*expression...*}]*. This option is *always
>    open* to us.
>
>
>    2. Use *$(*expression...*)*
>
>
>    3. Use *$((*expression...*))*
>
>
>    4. Use *[={*expression...*}]*
>
>
>    5. Use *[=* expression...*]*
>
>
>    6. Use *[(*expression...*)]*
>
>
>    7. Use something else (I've probably missed an option or two from this
>    painting of the bikeshed)
>
>
>
> Of the options above, 2 has *real *compatibility issues (i.e., we *know *it
> will clash with existing code in Tcllib) and 5 probably has semantic issues
> (because it was proposed as an actual command; anything that introduces
> uncontrolled double substitution is a no-no at this point). Option 3 has
> been assessed for practical compatibility, and should be fine (except for a
> few places in JimTcl, written by someone *already in this conversation*).
> Option 4 manages to be ugly, but is probably OK in terms of amount of
> in-the-wild usage. Option 6 hasn't been assessed yet.
>
>
>
> For all options that introduce a new syntactic substitution class, a
> change to *subst *is needed to work with it (Jan's outlined this
> adequately) and there should be consideration whether the other
> mini-languages inside Tcl should change (we have several).
>
>
>
> Donal.
>
>
> ------------------------------
>
> *From:* Florent Merlet <flo...@gm...>
> *Sent:* Thursday, October 23, 2025 09:32
> *To:* tcl...@li... <tcl...@li...>
> *Subject:* Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for
> Sponsorship
>
>
>
> Hello Jan, So we can admit that the implementation is not ready. In fact,
> expression is modelised like a variable and it can't nest. Fondamentally,
> the problem is that the « $ » sign allways has been related to the concept
> of variable, whereas
>
> Hello Jan,
>
> So we can admit that the implementation is not ready.
>
> In fact, expression is modelised like a variable and it can't nest.
>
> Fondamentally, the problem is that the « $ » sign allways has been related
> to the concept of variable, whereas an expression is related to the concept
> of command.
>
> « variables » have caracteristics that differ from the one of « commands »
> .
>
> « commands » can nest, whereas « variables » don't.
>
> These distinct caracteristics were translated directly in the programm
> flow, because, at a certain degree, there must be an analogy between the
> flow of the programm and the caracteristics of the concept.
>
> In Parse_token, the « $ » branch doesn't need to handle any nesting. Only
> the « [ » branch need to handle nesting.
>
> In fact, the proposal falls in the bad branch of « parse_Token », the «
> variable » branch, which tests for the presence of a « $ » char.
>
> The good branch for such an implementation is the « command » branch, that
> test for the presence of a « [ » char, because a command can nest.
>
> Conclusion : There is no real choice : the expr shorthand proposal must
> begin with a « [ », if not, the price paid by the source code will be too
> big, because of the radical difference between the « variable » and «
> command » concepts. At the end, you could have to recreate the flow for
> commands in the flow for variables.
>
> That's why, instead, I proposed this shorthand : « [( ... )] »
>
> It will be detected in the command branch of parse token, so that :
>
> 1. subst -noc can inhibit it : no need to change anything in the actual
> logic
>
> (an open question remains : how -nocommands et -noexpression flags will
> interfer, we may want -nocommand -withexpression after all)
>
> 2. We just have to check
>
>  } else if (*src == '[' && src[1] =='(') {
>
>     if (noSubstExpr) {
>         tokenPtr->type = TCL_TOKEN_TEXT;
>         tokenPtr->size = 2;
>         parsePtr->numTokens++;
>         src+=2;
>         numBytes-=2;
>         continue;
>         }
>
>     Tcl_Parse *nestedPtr;   src+=2;  numBytes-=2;
>
>     int length = tclParseExpression(src); // to be created :
>
>    opnode *opnode
>
>    nestedPtr = (Tcl_Parse *)TclStackAlloc(parsePtr->interp,
> sizeof(Tcl_Parse));
>
>    if (Tcl_ParseExpr(interp, src, -1, nestedPtr) != TCL_OK) {...}
>
>    ...etc
>
> I think, globally, this would be a simpler change, since we are not mixing carrots and potatoes.
>
> Honnestly, is the following code so bad visualy ?
>
> % set script [subst -noc {
>
>     set x [(1+1)]
>
> }]
>
> % set a 2
>
> % set script [subst -nov {
>
>    set x [(2+$a)]
>
> }]
>
> % set x [( 3 + [(3+3)] )]
>
> % set x [expr {4+[(4+4)]}]
>
>
>
>
>
>
>
> Le 23/10/2025 à 09:43, Jan Nijtmans a écrit :
>
> Op do 23 okt 2025 om 07:56 schreef Florent Merlet:
>
> What are the results of these commands:
>
> % set script [subst -noc {
>
>     set x $(1+1)
>
> }]
>
>
>
>     set x 2
>
>
>
> % set a 2
>
> 2
>
> % set script [subst -nov {
>
>    set x $(2+$a)
>
> }]
>
>
>
>    set x 4
>
>
>
> % set x $(3+$(3+3))
>
> invalid character "$"
>
> in expression "3+$(3+3)"
>
> % set x [expr {4+$(4+4)}]
>
> invalid character "$"
>
> in expression "4+$(4+4)"
>
> %
>
>
>
> I think all of those are expected. The first answer does
>
> "expr" substitution, the option "-noc" doesn't change
>
> anything on that (-noexpr would!). The second one
>
> also does expr substitution, the variable $a is handled
>
> by the expr handling itself. So that's expected too.
>
>
>
> The latter 2 are also as I expect, since $( substitution
>
> should not be done within expressions itself.
>
>
>
> This test is done with the version in the fossil "tip-672"
>
> branch. This branch is based on an earlier version from Eric.
>
> (@eric, could you base later changes on this version?
>
> you use a non-standard indenting, that makes merging
>
> in later versions rather cumbersome)
>
>
>
> One thing already discussed was to adapt the "subst"
>
> command for the new substitution. The tip-672 branch
>
> adds new -expr and -noexpr options, so the new proposed
>
> substitution can be switched on or off at will. I think
>
> that should be added to the TIP text.
>
>
>
> For now, I'll wait for the result of the discussion.
>
>
>
> Florent Merlet wrote:
>
> Is it to make people to go far away from Tcl ?
>
> Such accusations don't help anything in this
>
> discussion. That's all I'm going to say about it.
>
> Hope this helps,
>
>        Jan Nijtmans
>
>
>
>
>
> _______________________________________________
>
> Tcl-Core mailing list
>
> Tcl...@li...
>
> https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net] <https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!G2apoGRhxYjjkcB234n_qe1j3E65OHgCeKrFVRNGPkptfDmsAOCfgWEx4K2_YpAcsWbWY_5Bm2XkftSqpPt9ZcYmA1AMGovG0wSuHcY$>
>
> --
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

5 is basically equivalent to 1, it’s just a convention.

From: Donal Fellows <don...@ma...>
Date: Thursday, October 23, 2025 at 06:15
To: Florent Merlet <flo...@gm...>, tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship
​ Conclusion : There is no real choice ​ That's an incorrect conclusion. At least one of the priors you use in reaching it is invalid. The core of the proposal is that the sequence $( start a new syntax category (with what follows being an expression

​

Conclusion : There is no real choice

​
That's an incorrect conclusion. At least one of the priors you use in reaching it is invalid.

The core of the proposal is that the sequence $( start a new syntax category (with what follows being an expression to the point where there's a matching parenthesis using an appropriate recursive matching algorithm, with a similar model to how command substitutions work). This new syntactic entity will be called (almost certainly) an expression substitution. That it starts with $ is good; existing code that inserts backslashes before dollar signs to make things subst-safe will not be surprised; normally we'd recommend such approaches instead now switch to using regsub -command, due to the way subst works, but that's a longer-term change-over.

That the C code inside the Tcl parsing engine will need to change to accommodate a new syntax category isn't a deep insight. Of course it will need to change. Such change is what is being proposed!

Right now, the real discussion is what the sequence of literal characters in a Tcl script to introduce the new syntax should be. The options in play are:


  1.  Do nothing. Stick with [expr {expression...}]. This option is always open to us.

  1.  Use $(expression...)

  1.  Use $((expression...))

  1.  Use [={expression...}]

  1.  Use [= expression...]

  1.  Use [(expression...)]

  1.  Use something else (I've probably missed an option or two from this painting of the bikeshed)

Of the options above, 2 has real compatibility issues (i.e., we know it will clash with existing code in Tcllib) and 5 probably has semantic issues (because it was proposed as an actual command; anything that introduces uncontrolled double substitution is a no-no at this point). Option 3 has been assessed for practical compatibility, and should be fine (except for a few places in JimTcl, written by someone already in this conversation). Option 4 manages to be ugly, but is probably OK in terms of amount of in-the-wild usage. Option 6 hasn't been assessed yet.

For all options that introduce a new syntactic substitution class, a change to subst is needed to work with it (Jan's outlined this adequately) and there should be consideration whether the other mini-languages inside Tcl should change (we have several).

Donal.

________________________________
From: Florent Merlet <flo...@gm...>
Sent: Thursday, October 23, 2025 09:32
To: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

Hello Jan, So we can admit that the implementation is not ready. In fact, expression is modelised like a variable and it can't nest. Fondamentally, the problem is that the « $ » sign allways has been related to the concept of variable, whereas

Hello Jan,

So we can admit that the implementation is not ready.

In fact, expression is modelised like a variable and it can't nest.

Fondamentally, the problem is that the « $ » sign allways has been related to the concept of variable, whereas an expression is related to the concept of command.

« variables » have caracteristics that differ from the one of « commands » .

« commands » can nest, whereas « variables » don't.

These distinct caracteristics were translated directly in the programm flow, because, at a certain degree, there must be an analogy between the flow of the programm and the caracteristics of the concept.

In Parse_token, the « $ » branch doesn't need to handle any nesting. Only the « [ » branch need to handle nesting.

In fact, the proposal falls in the bad branch of « parse_Token », the « variable » branch, which tests for the presence of a « $ » char.

The good branch for such an implementation is the « command » branch, that test for the presence of a « [ » char, because a command can nest.

Conclusion : There is no real choice : the expr shorthand proposal must begin with a « [ », if not, the price paid by the source code will be too big, because of the radical difference between the « variable » and « command » concepts. At the end, you could have to recreate the flow for commands in the flow for variables.

That's why, instead, I proposed this shorthand : « [( ... )] »

It will be detected in the command branch of parse token, so that :

1. subst -noc can inhibit it : no need to change anything in the actual logic

(an open question remains : how -nocommands et -noexpression flags will interfer, we may want -nocommand -withexpression after all)

2. We just have to check

 } else if (*src == '[' && src[1] =='(') {

    if (noSubstExpr) {
        tokenPtr->type = TCL_TOKEN_TEXT;
        tokenPtr->size = 2;
        parsePtr->numTokens++;
        src+=2;
        numBytes-=2;
        continue;
        }

    Tcl_Parse *nestedPtr;   src+=2;  numBytes-=2;

    int length = tclParseExpression(src); // to be created :

   opnode *opnode

   nestedPtr = (Tcl_Parse *)TclStackAlloc(parsePtr->interp, sizeof(Tcl_Parse));

   if (Tcl_ParseExpr(interp, src, -1, nestedPtr) != TCL_OK) {...}

   ...etc

I think, globally, this would be a simpler change, since we are not mixing carrots and potatoes.

Honnestly, is the following code so bad visualy ?

% set script [subst -noc {

    set x [(1+1)]

}]

% set a 2

% set script [subst -nov {

   set x [(2+$a)]

}]

% set x [( 3 + [(3+3)] )]

% set x [expr {4+[(4+4)]}]






Le 23/10/2025 à 09:43, Jan Nijtmans a écrit :

Op do 23 okt 2025 om 07:56 schreef Florent Merlet:

What are the results of these commands:

% set script [subst -noc {

    set x $(1+1)

}]



    set x 2



% set a 2

2

% set script [subst -nov {

   set x $(2+$a)

}]



   set x 4



% set x $(3+$(3+3))

invalid character "$"

in expression "3+$(3+3)"

% set x [expr {4+$(4+4)}]

invalid character "$"

in expression "4+$(4+4)"

%



I think all of those are expected. The first answer does

"expr" substitution, the option "-noc" doesn't change

anything on that (-noexpr would!). The second one

also does expr substitution, the variable $a is handled

by the expr handling itself. So that's expected too.



The latter 2 are also as I expect, since $( substitution

should not be done within expressions itself.



This test is done with the version in the fossil "tip-672"

branch. This branch is based on an earlier version from Eric.

(@eric, could you base later changes on this version?

you use a non-standard indenting, that makes merging

in later versions rather cumbersome)



One thing already discussed was to adapt the "subst"

command for the new substitution. The tip-672 branch

adds new -expr and -noexpr options, so the new proposed

substitution can be switched on or off at will. I think

that should be added to the TIP text.



For now, I'll wait for the result of the discussion.



Florent Merlet wrote:

Is it to make people to go far away from Tcl ?

Such accusations don't help anything in this

discussion. That's all I'm going to say about it.

Hope this helps,

       Jan Nijtmans





_______________________________________________

Tcl-Core mailing list

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

https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https:/lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!G2apoGRhxYjjkcB234n_qe1j3E65OHgCeKrFVRNGPkptfDmsAOCfgWEx4K2_YpAcsWbWY_5Bm2XkftSqpPt9ZcYmA1AMGovG0wSuHcY$>
--

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

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

Le 23/10/2025 à 13:11, Donal Fellows a écrit :
> ​
>
> 	
> Conclusion : There is no real choice
>
> ​
> That's an incorrect conclusion. At least one of the priors you use in 
> reaching it is invalid.
> The core of the proposal is that the sequence *$(* start a 
> /new/ syntax category (with what follows being an expression to the 
> point where there's a /matching /parenthesis using an appropriate 
> recursive matching algorithm, with a similar model to how command 
> substitutions work). This new syntactic entity will be called (almost 
> certainly) an /expression substitution/. That it starts with *$* is 
> good; existing code that inserts backslashes before dollar signs to 
> make things *subst*-safe will not be surprised; normally we'd 
> recommend such approaches instead now switch to using *regsub 
> -command*, due to the way *subst *works, but that's a longer-term 
> change-over.
>
> That the C code inside the Tcl parsing engine will need to change to 
> accommodate a new syntax category isn't a deep insight. Of course it 
> will need to change. Such change is what is being proposed!

But there is change, and change.

- in matter of quantity : Which syntax will lead to the minimal change 
in the c-code ?

- in matter of quality : Which syntax will give the cleaner c-code for 
the reader ?


About this proposal « $(...) »

in matter of quality, the fact that the expression substitution is 
detected in a procedure whose name is Tcl_ParseVarname is highly 
illogical (not clean)

in matter of quantity, the fact that :

  - subst is defeat (confusion of variable and math expression) will 
imply corrections, whereas it's just the consequence of the previous 
conception illogicality (more code)

  - the impossibility of this new syntax to nest will imply corrections 
in Parse_Expr (more code)

  - the necessity to track memlink will imply more changed too (more code)


About the proposal « [( ... )] »

In matter of quality, the fact that a math expression is a command is 
logical (more clean)

In matter of quantity :

  - subst won't be defeat : no command, no expression : no change 
needed, but new feature possible of course (less code)

  - The syntax may easily nest, since it will fall in the SCRIPT case of 
the /Parse_Expr/ procedure, that will call /Tcl_ParseCommand/ then 
/Parse_Token/ (less code)

> Right now, the real discussion is what the sequence of literal 
> characters in a Tcl script to introduce the new syntax should be. The 
> options in play are:
>
> 1.
>     Do nothing. Stick with *[expr {*expression...*}]*. This option is
>     /always open/ to us.
> 2.
>     Use *$(*expression...*)*
> 3.
>     Use *$((*expression...*))*
> 4.
>     Use *[={*expression...*}]*
> 5.
>     Use *[=* expression...*]*
> 6.
>     Use *[(*expression...*)]*
> 7.
>     Use something else (I've probably missed an option or two from
>     this painting of the bikeshed)
>
The better way be should to implement each of these proposals and 
compare it in quantity as well as in quality.

I really would like to implement the « [( ... )] » variant, sadly, I 
have neither the time, neither the infrastructure, neither the 
competence to do so.

I am absolutely sure the result will be, finally, simpler than the other 
alternatives (since an expression is a kind of command...)

Is someone interesting to get a try ?

Florent

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

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

On Tue, 21 Oct 2025 08:02:55 +0000
Zaumseil René via Tcl-Core <tcl...@li...> wrote:

> Hello
> 
> I currently do not see the benefit of this proposal, except some char less to type.
> IMHO expr has some problems or room for enhancements:
> 
>   1.  Double evaluation of arguments
> 
> Could be solved with a new command with only 1 argument
> 
>   1.  Returns only one value
> 
> See p.e. tip 647 syntax

In case you are interested, I wrote a quick POC of tip 647, available at

https://chiselapp.com/user/egavilan/repository/mexpr

Sample usage:

# 1 argument
% package require mexpr
0.1
% ::mexpr::let {
    a {rand()}
    b {3*$a}
    b {sqrt($b)}
}
0.6664191757638097 1.9992575272914292 1.4139510342623005
% list $a $b
0.6664191757638097 1.4139510342623005

# multiple arguments
% ::mexpr::let a {rand()} b {3*$a} b {sqrt($b)}
0.5070870623491178 1.5212611870473536 1.2333941734284923
% list $a $b
0.5070870623491178 1.2333941734284923

# 1 argument, using -local
% unset a b
% ::mexpr::let -local {
    a {rand()}
    b {3*$a}
    b {sqrt($b)}
}
0.20174559122032745 0.6052367736609824 0.7779696482903317
list $a $b
can't read "a": no such variable

# with -local, all referenced variables must be either defined first
# or reached using their qualified name
% set c 4
4
% ::mexpr::let -local b {3 * $c}
can't read "c": no such variable
% ::mexpr::let -local b {3 * $::c}
12

I've left out the magic variable names; all set values are collected
and returned.

Feel free to change and experiment.

Regards

-- 
Emiliano

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

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

Hi Eric,

On 10/22/25 10:12 PM, EricT wrote:
> This works both before and after the feature if adopted, so code can 
> be migrated proactively. The pragma approach would help identify all 
> $() uses that need updating.

So you appear to be confirming that changing the [expr] syntax *will* 
have side effects that require changes in other code.

I'm generally agnostic about language changes to Tcl, and I don't have a 
strong opinion about the various alternatives presented in this 
discussion. I'll leave that to the experts.

However, the cranky, "don't make it worse" developer in me is prompted 
to ask: Why should other parts of my code have to change to accommodate 
this language update that I may not even use?

If the answer is, "We are now in Tcl 9, and breaking changes are OK," my 
response is, "Sure, that was true for 9.0. The breaking changes were 
planned and long communicated."

In other words -  the issue is not really variable substitution in 
itself, but whether the window for breaking changes is still open. I 
thought we were done with that and the window is now closed.

That's more of a question for the TCT as a whole, and I don't have the 
answer. I am inclined to vote against a TIP with breaking changes 
because I don't like breaking changes, but I am open to being persuaded 
on the larger topic - that we are not done making those kinds of changes 
to the language and it's OK.

--Kevin