tcl-core — Tcl Core Team discussions about Tcl development

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

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

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

[Hmm, looks like I forget to send this...]

My point was severalfold:

  1.
The shell syntax had double-parenthesis.
  2.
A search for that exact syntax in Tcl code yielded almost no valid results; only JimTcl code appears to be currently affected. The search was only of code that's public, but that acts as a sampler for the space of non-public code.
  3.
The syntax $((...)) is therefore concluded to be available whereas the shorter $(...) syntax is contested; we're talking about two or three orders of magnitude more instances. That's going to be significant migration trouble. Nobody appears to be using literal array keys that start and end with parentheses in practice.
     *
The cases where they're using keys which contain them and are using an empty-named array don't count; the syntax must be starting with exactly $(( or $( for the syntax to trigger
     *
Updating the implementation proposed syntax (plus the TIP) to $((...)) is less work than tracking down all the places broken by sticking to $(...).
  4.
$((...)) is still nicer and shorter and easier to type than [expr {...}]; the syntax feature will likely reduce bugs.

One doesn't always get exactly what one wants. You've won almost all the arguments (and easily) except for the one about the syntax, where it turns out it's being used in practice for other purposes. In many places. This is where my TCT hat gets involved: I have to consider all that other code as well as your proposal.

What follows will be heated discussion. Syntax discussions have historically always been so.

Donal.

________________________________
From: EricT <tw...@gm...>
Sent: Tuesday, October 21, 2025 13:36
To: Donal Fellows <don...@ma...>
Cc: Brian Griffin <bri...@ea...>; tc...@ro... <tc...@ro...>; Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax

Hi Donal:

Yes, I should have been more careful with that. I see that it is actually $((...)) in bash.

I think the best approach is to find all the uses by both searching and also a pragma that optionally will cause any use of $() to be flagged with an error. Then convert to using one of the two alternative methods.

I understand empty array names exist in production code. It's also important to note that ${()} doesn't work for all cases - it only handles literal indices. When the index involves variable substitution (like $($var)), users must use [set (...)] instead.

The migration path is clear I believe: use [set (...)] which works for all cases, both before and after the feature is enabled.

Thanks again for the feedback.

Eric


On Tue, Oct 21, 2025 at 1:55 AM Donal Fellows <don...@ma...<mailto:don...@ma...>> wrote:
​
EricT2025-10-21 04:12
1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.
​
Surely the better shell precedent would be the $((expression)) form? That would also be quite a bit less likely to clash with existing use cases. Hmm, a quick search with https://github.com/search?q=%24%28%28+language%3ATcl&type=code [github.com]<https://urldefense.com/v3/__https://github.com/search?q=*24*28*28*language*3ATcl&type=code__;JSUlKyU!!PDiH4ENfjr2_Jw!Eot1BTBAjUrPeBxEg8km_8tqRFXpHzfHkiNZX7qagLMYARtCjwfj3_uX-YkRBZbGR4sbbT_P-u3u9zqo38ySjFCk4pY$> gives 29 hits (most of which appear to be false positives; the real hits seem to be from one place in JimTcl itself), as opposed to 4k hits when looking for $( in Tcl code; two orders of magnitude less usage. One of the really nice things about a resource like GitHub is that one can quickly search for language syntax features across a lot of code and get a good feeling for practical compatibility.

While $(([llength $x] - 17)) is no shorter than {=}{[llength $x] - 17}, it's definitely easier to type!

(Eric: Don't lose heart! These discussions are a lot less acrimonious than the discussion over what became {*} was.)

Donal.

________________________________
From: EricT <tw...@gm...<mailto:tw...@gm...>>
Sent: Tuesday, October 21, 2025 04:11
To: Brian Griffin <bri...@ea...<mailto:bri...@ea...>>
Cc: tc...@ro...<mailto:tc...@ro...> <tc...@ro...<mailto:tc...@ro...>>; Tcl Core List <tcl...@li...<mailto:tcl...@li...>>
Subject: Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax

Thanks for the feedback, Brian! I understand your concern about the semantic distinction between $ (value) and [ ] (execution).

I'd offer a few thoughts:

1. Shell precedent: The $(command) syntax is well-established in bash/sh for command substitution. Tcl users familiar with shell scripting would find this natural, not confusing.

2. $ already involves execution: Even $var involves command execution internally (TclGetVar), it's just optimized. The distinction between "value substitution" and "command execution" is somewhat artificial at the implementation level.

3.  expr is special and has historical precedent: Unlike arbitrary commands, expr is used so frequently that syntactic sugar makes sense - similar to how $var is sugar for [set var]. We optimize the common case. I believe there was a time in early Tcl before $var existed when [set var] was the only choice - if so, adding $var as syntactic sugar for variable substitution was a usability win. $(expr) follows the same pattern - sugar for the extremely common [expr {...}] case.

4. Consistency: $(expr) fits the pattern of "$ means substitute something here" - whether a variable, array element, or expression result. Modern languages like Python have embraced similar concepts with f-strings that allow {expression} for inline evaluation. $(expr) brings this convenience to Tcl while maintaining our substitution semantics.

That said, I appreciate the philosophical consistency argument. Do you see the security benefits (auto-bracing) as compelling enough to outweigh the semantic concern?

Did you see the email I sent you about lseq? Maybe it landed in your spam folder - that happened once before as I recall.

Eric


On Mon, Oct 20, 2025 at 7:19 PM Brian Griffin <bri...@ea...<mailto:bri...@ea...>> wrote:
I like the idea of simplifying expression substitutions.  The problem I have is that the '$' is defined to be a value substitution. Running a command (execution) is a [] substitution, not a '$' substitution.  Conflating the two modes of substitution can cause confusion for newbies, and even experienced programmers.

I recognize that this view is a very subtle distinction, but I think it's important.

Think of it like conflating * vs & in C.  (Maybe not that bad, but similar)

-Brian

On Oct 20, 2025, at 07:22, EricT <tw...@gm...<mailto:tw...@gm...>> wrote:

Regarding the discussion in the telco today. If the incompatibility discussed is the known empty array issue, then for that I would propose the following:

There could be a pragma or tcl_dollar_expr global variable with several settings.

1. Work in compatibility mode, i.e. as though the feature was not implemented at all.
2. Work in diagnostic mode, throw an error for any $(...) use
3. Work in full implementation mode

The code to do this, given a global C variable to check would be trivial.

This value could default to 1. for at least 9.1 or 9.2 but there could be an option, similar to tclsh -encoding, that would allow the pragma variable to be set before any init script code is run. This would give developers the opportunity to set the variable to mode 2 in order to easily track down uses of $(index) before any code were to begin using $(expr).

I think it would be quite rare if this syntax change would affect binary extensions, so it should be only with script level coding.

The fix to any code that is using the empty array variable, is to change from,

    set val $(index)
    set val $($var)  - or any other valid index string

to

   set val ${(index)}
   set val ${($var)}

Likewise for any other use of the $(...) substitution in current use.

This change can begin to be made right away, since it is a compatible syntax that does not change the semantics.  Once all the init time script code or packages that use the un-braced syntax are found and changed, the feature could begin to be used by those who are interested.

On the other hand, if the incompatibility is something other than this empty array, I'd be most appreciative to know what it is.

thanks

Eric


On Sun, Oct 19, 2025 at 3:44 AM EricT <tw...@gm...<mailto:tw...@gm...>> wrote:
Harald,

Thank you for your willingness to sponsor!

To clarify: I am not the author of Jim Tcl - I'm just a long-time Tcl user who, in retirement, wanted to give something back to the Tcl community. Jim Tcl's successful use of this syntax for years demonstrates that the concept is viable.

Regarding the telco: I attempted to join previously but was unsuccessful with the setup. I won't be able to participate on Monday, but I'm available via email for any questions or clarifications that arise from the discussion.

I don't currently have write access to either the Tcl Fossil repository or the TIP repository, so I'm unable to make changes directly. At nearly 80 years old, I'm not comfortable learning new version control systems on my own. If the TIP moves forward, I'd need guidance and assistance with the Fossil workflow, or perhaps someone from the core team who shares our interest in this TIP could handle the integration based on my GitHub prototype.

I'm currently developing a comprehensive test suite in standard tcltest format, with particular focus on edge cases.

Looking forward to hearing how Monday's discussion goes!

Best regards,
Eric


On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <har...@el...<mailto:har...@el...>> wrote:
Eric,
sponsoring is no problem. The point is to get positive votes.
This requires a positive discussion.
You are the Author of Jim?
Could you participate on the telco on Monday?

Do you have write access to the tcl fossil? We would need the
implementation there.

Thanks for all,
Harald

Am 18.10.2025 um 22:58 schrieb EricT:
> Thank you for the positive feedback and for raising this in Monday's
> telco! I'm encouraged by your support.
>
> Regarding $(a) - you're right that reading an empty array element with a
> variable index is a valid construct. However, this is explicitly
> addressed in the TIP and the repository README. The workarounds are
> straightforward:
>
>    ${(a)}        # Braced form
>    [set (a)]     # Command substitution
>
> Both still work. In fact, code using $(varname) could be proactively
> modified to use ${(varname)} to indicate the clear intent of an empty
> array reference, which improves readability. The security, performance,
> and usability benefits of $(...) seemed to justify this trade-off for
> Tcl 9.x where some incompatibilities are expected.
>
> Given your interest in the feature, would you be willing to consider
> sponsoring TIP 672? The implementation is working and minimal (~100
> lines across two files), with the main open question being the preferred
> approach for tracking synthetic strings for cleanup. Your guidance on
> that architectural decision would be particularly valuable.
>
> The prototype repository with full implementation and examples is here:
>
> https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$> <https://
> github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>>
>
> Looking forward to the results of the discussion on Monday! I won't be
> able to join the telco discussion, but I'm available via email for any
> questions or clarifications that arise.
>
>
> On Sat, Oct 18, 2025 at 1:09 PM Harald Oehlmann
> <har...@el...<mailto:har...@el...> <mailto:har...@el...<mailto:har...@el...>>> wrote:
>
>     Am 17.10.2025 um 23:22 schrieb EricT:
>      > Hello Tcl Core Team,
>      >
>      > I have developed a working prototype implementation of TIP 672,
>     which
>      > adds the $(expression) syntax as a more intuitive alternative to
>     [expr
>      > {expression}].
>      >
>      > Repository: https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>
>     <https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$>>
>      > <https://github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8buJgHl4$> <https://
>     github.com/rocketship88/tcl-tip-672-prototype [github.com]<https://urldefense.com/v3/__http://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl8aM1j4X0$>>>
>      >
>      > The implementation is minimal, modifying only two files
>     (tclParse.c and
>      > tclNamesp.c) with approximately 100 lines of changes. The key
>      > modification converts the existing two-way branch in
>     Tcl_ParseVarName to
>      > a three-way branch, with the new path handling $(...) by creating a
>      > synthetic [expr {...}] command string.
>      >
>      > Key Accomplishments:
>      >
>      > Full bytecode compilation: The synthetic string approach integrates
>      > seamlessly with the existing compiler, producing identical optimized
>      > bytecode as [expr {...}]. The disassembler output (shown in the
>     README)
>      > demonstrates efficient variable loading with no runtime parsing
>     overhead.
>      >
>      > Proven approach: Jim Tcl has used this syntax successfully for years
>      >
>      > Comprehensive testing: Works correctly with string interpolation,
>      > variable scoping, error handling, and interactive mode
>      >
>      > Known Limitations:
>      >
>      > Memory leak: The synthetic string is allocated but not tracked for
>      > cleanup in Tcl_FreeParse. This requires core team guidance on the
>      > preferred solution (modify Tcl_Parse structure vs. thread-local
>     tracking).
>      >
>      > Error messages: Currently show the synthetic command rather than the
>      > original $(...) syntax, though this is arguably helpful for
>     debugging.
>      >
>      > Questions for the Team:
>      >
>      > What is the preferred approach for tracking synthetic strings for
>     cleanup?
>      > Is this prototype architecture acceptable for Tcl 9.x?
>      > Are there concerns with the synthetic string approach that I
>     should address?
>      >
>      > The complete implementation with side-by-side diffs is available
>     in the
>      > repository. I'm happy to refine the code based on your feedback and
>      > would appreciate any guidance on moving this forward.
>      >
>      > Best regards,
>      > Eric
>     Eric,
>     great proposal, thank you !
>
>     Perhaps, we may discuss this on Monday in the biweekly telco.
>     I am also excited and in favor to this.
>     Nevertheless, "$(a)" is to my knowledge a quite common syntax for
>     arrays. We have already killed less disruptive proposals (see optional
>     "- args") by endless discussions and getting nowhere.
>     Hope, this will be fruitful.
>
>     In addition, I would like to add the Tk test reform by the other
>     Eric to
>     the biweekly topics.
>     Here is a revised agenda proposal proposal:
>
>     Top 1) Release calender (TIP 713)
>     - 9.0.3: October (2 weeks left)
>     - 9.1a1: November (6 weeks left)
>     Top 2) TIP 734 nested mutex (go or not)
>     Top 3) TIP 733: accessability (test status)
>     Top 4) TIP 732: TCL library path (discussion)
>     Top 5) TIP 731: use C enums (no brainer?)
>     Top 6) TIP 720: new bytecodes (final, great! Any issues?)
>     Top 7) TIP 721: Tcl_AttemptGetString
>     Top 8) TIP 715: supported build systems
>     Top 9) $($a+$b) syntax for expressions
>     Top 10) Tk test reform by Eric (Thanks !)
>     Top 11) Tcl depot and awthemes ?
>     Top 12) AOB
>     Top 13) Next meeting:
>           3rd of November 12:00 UTC.
>           Daytime saving time ends 2nd of November in US, 26th of
>     October in
>     Europe.
>           Will we keep 12:00 UTC ? Or 13:00 UTC, so Don has 8:00 AM?
>
>     Take care,
>     Harald
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>

_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Fnw2VZOkJIt0hYAyi7uMJpHn2oP79DlZ5A8fqXORtGo9BUUJ35XItI-pNGmBahGZVIO3H-Kc6D13fiFBnEl881_NXzE$>
_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core [lists.sourceforge.net]<https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!Eot1BTBAjUrPeBxEg8km_8tqRFXpHzfHkiNZX7qagLMYARtCjwfj3_uX-YkRBZbGR4sbbT_P-u3u9zqo38ySlCQMhbQ$>

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

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

​
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...<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...>]

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

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

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

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

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

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

Hello Eric,
Some questions / Tests

What are the results of these commands :

1.
% set script [subst -noc {
    set x $(1+1)
}]

2.
% set a 2
% set script [subst -nov {
    set x $(2+$a)
}]

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


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

Cordialy

FM



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

    Hi everyone,

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

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

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

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

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

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

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

    Best regards,
    Eric

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

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

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

Phillip:

Please get the latest from:

https://github.com/rocketship88/tcl-tip-672-prototype

There was a bug in the logic that handles the 2nd choice of $=(...) when
using an incomplete string interactively:

% puts $=

It wasn't looking far enough to find there wasn't a ( and when used
interactively caused an infinite loop of reparsing. The latest update has
that fix.

BTW, Here's the example I should have shown:



  % mkdir foobar

  % glob fo*
foo.tcl foobar

  % set x {1 + [file delete foobar] + 1}
1 + [file delete foobar] + 1

  % glob fo*
foo.tcl foobar

  % puts [expr $x + 1]
cannot use non-numeric string "" as right operand of "+"

  % glob fo*
foo.tcl

  % mkdir foobar

  % puts [expr {$x + 1}]
cannot use a list as left operand of "+"

  % glob fo*
foo.tcl foobar

  % puts $($x + 1)
cannot use a list as left operand of "+"

  % glob fo*
foo.tcl foobar

  % tcl::unsupported::disassemble script {puts $($x)}

ByteCode 0x22cd0a6fcc0, refCt 1, epoch 22, interp 0x22cca19b050 (epoch 22)
  Source "puts $($x)"
  Cmds 2, src 10, inst 27, litObjs 2, aux 0, stkDepth 2, code/src 0.00
  Commands 2:
      1: pc 0-25, src 0-9        2: pc 5-20, src 2465-2473
  Command 1: "puts $($x)"
    (0) push 0 # "puts"
  Command 2: "expr {$x}..."
    (5) startCommand +16 1 # next cmd at pc 21, 1 cmds start here
    (14) push 1 # "x"
    (19) loadStk
    (20) tryCvtToNumeric
    (21) invokeStk 2
    (26) done

Eric




On Wed, Oct 22, 2025 at 8:41 PM Phillip Brooks <phi...@um...> wrote:

> I think the $(( … )) syntax it being left out of this discussion - it has
> the intuitive advantage of $( … ) since the $(( … )) syntax is used in
> bash. It has no known incompatibilities with currently valid syntax.
>
> I am working on adapting Eric’s code to handle $(( … )).  I won’t be able
> to look at it for the next couple of days, but expect to work on it some
> next week.
>
> Don, can you think of a way to test your questions concerning
> environments? Perhaps some upvar et al trickery?
>
> Phil
>
> On Wed, Oct 22, 2025 at 8:00 PM EricT <tw...@gm...> wrote:
>
>> More examples:
>>
>>   % set a "\$(1+2)"
>> $(1+2)
>>
>>   % set a "$(1+2)"
>> 3
>>
>>   % set a "a = $(1+2)"
>> a = 3
>>
>>   % set a "a = \$(1+2)"
>> a = $(1+2)
>>
>>   % string length $(1+2)
>> 1
>>
>>   % string length \$(1+2)
>> 6
>>
>>   % string range  \$(1+2) 0 3
>> $(1+
>>
>>   % string range  \$(1+2) 0 3+1
>> $(1+2
>>
>>   % string range  \$(1+2) 0 3*1
>> bad index "3*1": must be integer?[+-]integer? or end?[+-]integer?
>>
>>   % string range  \$(1+2) 0 $(3*1)
>> $(1+
>>
>>   % string range  \$(1+2) 0 $(3*2-2)
>> $(1+2
>>
>>   % set n 5
>> 5
>>
>>   % lseq 1 to $($n *2)
>> 1 2 3 4 5 6 7 8 9 10
>>
>>   % puts $
>> $
>>
>>   % puts \$(
>> $(
>>
>>  % puts $(
>> > 5 + 10
>> > )
>> 15
>>
>>
>> On Wed, Oct 22, 2025 at 7:12 PM EricT <tw...@gm...> wrote:
>>
>>> Don:
>>>
>>> % set a $(1+2)
>>> 3
>>> % set a \$(1+2)
>>> $(1+2)
>>>
>>> Kevin:
>>>
>>> In Tcl, array names can be empty strings. So this is valid:
>>>
>>> set (index) "value"     # Array with empty name ""
>>> puts $(index)           # Read from array "" at index "index"
>>>
>>> With $(...) syntax for expressions, there's ambiguity:
>>>
>>> $(10)                   # Array "" at index "10"? Or an expression
>>> returning 10?
>>>
>>> The parser can't tell which you meant.
>>>
>>> The workaround for empty array access:
>>>
>>> [set (index)]           # Use [set] command instead of $ substitution
>>> [set (10)]              # For numeric indices too
>>>
>>> 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.
>>>
>>> With $=(...), there's no conflict:
>>>
>>> $(10)                   # Still array "" at index "10" (no = after $)
>>> $=(10)                  # Clearly an expression returning 10
>>>
>>> That's why some prefer $=(...) - it completely avoids the empty array
>>> name issue while others prefer the simpler $(...) syntax despite requiring
>>> migration for the edge case.
>>>
>>> The core team would choose which implementation to adopt (not both at
>>> the same time) should the TIP be approved.
>>>
>>> On Wed, Oct 22, 2025 at 6:39 PM Kevin Walzer <kw...@co...> wrote:
>>>
>>>> Hi Eric,
>>>>
>>>> I’m referring to this section of the TIP:
>>>>
>>>> —-
>>>>
>>>> One incompatibility is that it would require that the use of the null
>>>> string "" or {} as an array name would require a change from using $
>>>> substituion to using the 2 argument form of the set command.
>>>>
>>>> Thus, to assign the variable "" to a value, would still work for both
>>>> scalars and array variables, as in:
>>>>
>>>>   set {} foobar             ;# scalar variable
>>>>   set (index) "array value" ;# array variable
>>>>
>>>> But the use of $(index) would have to change by using the set command:
>>>>
>>>>   set var [set (index)]
>>>>
>>>> One other possible incompatibility would be with the use of the subst
>>>> command. The issue here is whether $(...) would be a command or
>>>> variable substitution that subst has options to suppress.
>>>>
>>>> —-
>>>>
>>>> Can you explain?
>>>>
>>>>
>>>> —Kevin
>>>>
>>>> On Oct 22, 2025, at 9:13 PM, EricT <tw...@gm...> wrote:
>>>>
>>>> 
>>>>
>>>> Hi Kevin,
>>>>
>>>> Variable substitution doesn't change at all. $(expr) or $=(expr) is
>>>> purely syntactic sugar that transforms to [expr {expr}] before any
>>>> substitution happens.
>>>>
>>>> The flow is:
>>>> 1. Parser sees $(5 + $x) or $=(5 + $x)
>>>> 2. Transforms it to [expr {5 + $x}] (synthetic)
>>>> 3. Normal Tcl substitution and evaluation proceed
>>>>
>>>> So $(expr) or $=(expr) is just as self-contained as [expr] - it's the
>>>> exact same thing underneath, just with cleaner syntax for the common case
>>>> of inline expressions.
>>>>
>>>> The tradeoffs differ slightly by syntax choice:
>>>>
>>>> $(...): More intuitive (matches shell and jimtcl), but conflicts with
>>>> empty array name edge case
>>>> $=(...): No conflicts, but affects literal $=( (extremely rare, easily
>>>> escaped)
>>>>
>>>> Both provide: More readable code, auto-braced (safer), less typing
>>>>
>>>> You can learn more in the README at:
>>>> https://github.com/rocketship88/tcl-tip-672-prototype
>>>>
>>>> Eric
>>>>
>>>>
>>>> On Wed, Oct 22, 2025 at 12:09 PM Kevin Walzer <kw...@co...>
>>>> wrote:
>>>>
>>>>> This will be a hard sale for me. I have yet to fully understand the
>>>>> tradeoffs, ie does variable substitution change?  [expr] is ugly but it is
>>>>> self-contained.
>>>>>
>>>>> On Oct 22, 2025, at 2:44 PM, da Silva, Peter J <
>>>>> pet...@fl...> wrote:
>>>>>
>>>>> 
>>>>>
>>>>> That doesn’t seem any better than “set x [= {$y + 1}]”
>>>>>
>>>>>
>>>>>
>>>>> And the Unicode version gives me flashbacks to early Smalltalk and APL.
>>>>>
>>>>>
>>>>>
>>>>> I started out in favor of the “$(...)” syntax but this is turning into
>>>>> creeping Perlism.
>>>>>
>>>>>
>>>>>
>>>>> *From: *Florent Merlet <flo...@gm...>
>>>>> *Date: *Wednesday, October 22, 2025 at 13:20
>>>>> *To: *Zaumseil René <RZa...@kk...>, tc...@ro... <
>>>>> tc...@ro...>
>>>>> *Cc: *et...@ro... <et...@ro...>,
>>>>> tcl...@li... <Tcl...@li...>
>>>>> *Subject: *Re: [TCLCORE] [Ext] Re: TIP 672 Implementation Complete -
>>>>> Ready for Sponsorship
>>>>>
>>>>> Another alternative proposal : set x [($y+1)] It is very readable,
>>>>> easy to write, there is eventually a unicode version set x 〖$y+1〗 1 .
>>>>> We define a new kind of substitution RULE [7'] Expression substitution : If
>>>>> a word contains an open bracket
>>>>>
>>>>> Another alternative proposal :
>>>>>
>>>>> set x [($y+1)]
>>>>>
>>>>> It is very readable, easy to write, there is eventually a unicode
>>>>> version
>>>>>
>>>>> set x 〖$y+1〗
>>>>>
>>>>> 1 . We define a new kind of substitution
>>>>>
>>>>> RULE [7'] Expression substitution :
>>>>>
>>>>> If a word contains an open bracket *« [ »* immediately followed by an
>>>>> open parenthesis « ( », then Tcl performs an Expression substitution. To do
>>>>> this it invokes the Tcl interpreter recursively to process the characters
>>>>> following the open parenthesis as a Tcl mathematical Expression. The
>>>>> Expression must be terminated by a close bracket « *] » *immediately preceded
>>>>> by a closed parenthesis « ) ». The result of the expression is substituted
>>>>> into the word in place of the brackets-parenthesis and all of the
>>>>> characters between them. There may be any number of expression
>>>>> substitutions in a single word. Expression substitution is not performed on
>>>>> words enclosed in braces.
>>>>>
>>>>> 2. We create the test in ParseToken
>>>>>
>>>>> ... else if (*src == '[') {
>>>>>
>>>>>            if (src[1] == '(') {
>>>>>
>>>>>                      // Expression substitution
>>>>>
>>>>>                      // must finish by « )] »
>>>>>
>>>>>                     // doesn't know how to do it...
>>>>>
>>>>>             } else {
>>>>>
>>>>>                      // Command substitution
>>>>>
>>>>>             }
>>>>>
>>>>> 3. we create a -noexpr switch in the subst command
>>>>>
>>>>> ....
>>>>>
>>>>> Examples :
>>>>>
>>>>> inline expression :  string range "my long sentence" 0 end-[($x+2)]
>>>>>
>>>>> With native list expr enancement :  .c create rectangle {*}[( $X , $Y,
>>>>> $X+100, $Y+100 )]
>>>>>
>>>>> With multiples instructions enhancement :  set multiexpr [( x = 1; y =
>>>>> 2; $x-$y, $y-$x )]
>>>>>
>>>>> Readable, easy to type, test logically positionned in the C source
>>>>> code, no double substitution, avoiding confusion with variable substitution
>>>>> : This is the solution !
>>>>>
>>>>> Florent
>>>>>
>>>>>
>>>>>
>>>>> Le 22/10/2025 à 15:52, Zaumseil René a écrit :
>>>>>
>>>>> And how will this be documented? Imho it should be mentioned in the
>>>>> dodecalogue.
>>>>>
>>>>> Currently the used syntax is only used as array variable and not as
>>>>> math command.
>>>>>
>>>>> I remember the big discussion on {*} syntax here.
>>>>>
>>>>> Again, is this change really more readable and useable?
>>>>>
>>>>> Is the benefit worth the additional syntax.
>>>>>
>>>>> Why not create real benefit with p.e. a multiple set command ala tip
>>>>> 674.
>>>>>
>>>>> Or a new math command without need of $.. access to variables.
>>>>>
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> rene
>>>>>
>>>>>
>>>>>
>>>>> *Von:* Florent Merlet <flo...@gm...>
>>>>> <flo...@gm...>
>>>>> *Gesendet:* Mittwoch, 22. Oktober 2025 15:39
>>>>> *An:* tc...@ro...
>>>>> *Cc:* et...@ro...; tcl...@li...
>>>>> *Betreff:* [Ext] Re: [TCLCORE] TIP 672 Implementation Complete -
>>>>> Ready for Sponsorship
>>>>>
>>>>>
>>>>>
>>>>> So, everybody in the core team agree with the implementation of a new
>>>>> math-Expression substitution as a memlink command into the procedure in
>>>>> charge of variable name substitution ?
>>>>>
>>>>>
>>>>>
>>>>> Le mer. 22 oct. 2025, 14:07, EricT <tw...@gm...> a écrit :
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I wanted to update you on the status of TIP 672 (expression
>>>>> substitution syntax).
>>>>>
>>>>> The prototype implementation is now complete and available at:
>>>>> https://github.com/rocketship88/tcl-tip-672-prototype
>>>>> <https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=ZG5I9vay2CgB9hUAk2I-pkA-6Y6ofRO4-983kuM23Nw&e=>
>>>>>
>>>>> The implementation has been parameterized to support both discussed
>>>>> approaches with a simple compile-time flag:
>>>>> - Mode 1: $(expr) syntax
>>>>> - Mode 2: $=(expr) or $^(expr) - configurable character
>>>>>
>>>>> Key features:
>>>>> - Comprehensive test suite (82 tests covering edge cases)
>>>>> - Minimal code changes (~100 lines)
>>>>> - Clean integration with existing parser
>>>>> - Full Tcl test suite passes (only 3 expected differences)
>>>>>
>>>>> There is one known issue: a minor memory leak in the synthetic command
>>>>> strings that will need attention during integration.
>>>>>
>>>>> At this point, I need a sponsor to upload the code to a TIP branch on
>>>>> Fossil so the core team can review and decide whether to adopt the TIP and,
>>>>> if so, which syntax to use. I'm available for any collaborative work,
>>>>> questions, or modifications needed.
>>>>>
>>>>> I'm grateful for all the feedback and support from the community. I
>>>>> look forward to the next steps in the process.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Eric
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Tcl-Core mailing list
>>>>> Tcl...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>> <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=4iEQfafWSb-GM4h7dq1Qztghg-qOF6HjeF8W3XUHIzs&e=>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>> _______________________________________________
>> 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 think the $(( … )) syntax it being left out of this discussion - it has
the intuitive advantage of $( … ) since the $(( … )) syntax is used in
bash. It has no known incompatibilities with currently valid syntax.

I am working on adapting Eric’s code to handle $(( … )).  I won’t be able
to look at it for the next couple of days, but expect to work on it some
next week.

Don, can you think of a way to test your questions concerning environments?
Perhaps some upvar et al trickery?

Phil

On Wed, Oct 22, 2025 at 8:00 PM EricT <tw...@gm...> wrote:

> More examples:
>
>   % set a "\$(1+2)"
> $(1+2)
>
>   % set a "$(1+2)"
> 3
>
>   % set a "a = $(1+2)"
> a = 3
>
>   % set a "a = \$(1+2)"
> a = $(1+2)
>
>   % string length $(1+2)
> 1
>
>   % string length \$(1+2)
> 6
>
>   % string range  \$(1+2) 0 3
> $(1+
>
>   % string range  \$(1+2) 0 3+1
> $(1+2
>
>   % string range  \$(1+2) 0 3*1
> bad index "3*1": must be integer?[+-]integer? or end?[+-]integer?
>
>   % string range  \$(1+2) 0 $(3*1)
> $(1+
>
>   % string range  \$(1+2) 0 $(3*2-2)
> $(1+2
>
>   % set n 5
> 5
>
>   % lseq 1 to $($n *2)
> 1 2 3 4 5 6 7 8 9 10
>
>   % puts $
> $
>
>   % puts \$(
> $(
>
>  % puts $(
> > 5 + 10
> > )
> 15
>
>
> On Wed, Oct 22, 2025 at 7:12 PM EricT <tw...@gm...> wrote:
>
>> Don:
>>
>> % set a $(1+2)
>> 3
>> % set a \$(1+2)
>> $(1+2)
>>
>> Kevin:
>>
>> In Tcl, array names can be empty strings. So this is valid:
>>
>> set (index) "value"     # Array with empty name ""
>> puts $(index)           # Read from array "" at index "index"
>>
>> With $(...) syntax for expressions, there's ambiguity:
>>
>> $(10)                   # Array "" at index "10"? Or an expression
>> returning 10?
>>
>> The parser can't tell which you meant.
>>
>> The workaround for empty array access:
>>
>> [set (index)]           # Use [set] command instead of $ substitution
>> [set (10)]              # For numeric indices too
>>
>> 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.
>>
>> With $=(...), there's no conflict:
>>
>> $(10)                   # Still array "" at index "10" (no = after $)
>> $=(10)                  # Clearly an expression returning 10
>>
>> That's why some prefer $=(...) - it completely avoids the empty array
>> name issue while others prefer the simpler $(...) syntax despite requiring
>> migration for the edge case.
>>
>> The core team would choose which implementation to adopt (not both at the
>> same time) should the TIP be approved.
>>
>> On Wed, Oct 22, 2025 at 6:39 PM Kevin Walzer <kw...@co...> wrote:
>>
>>> Hi Eric,
>>>
>>> I’m referring to this section of the TIP:
>>>
>>> —-
>>>
>>> One incompatibility is that it would require that the use of the null
>>> string "" or {} as an array name would require a change from using $
>>> substituion to using the 2 argument form of the set command.
>>>
>>> Thus, to assign the variable "" to a value, would still work for both
>>> scalars and array variables, as in:
>>>
>>>   set {} foobar             ;# scalar variable
>>>   set (index) "array value" ;# array variable
>>>
>>> But the use of $(index) would have to change by using the set command:
>>>
>>>   set var [set (index)]
>>>
>>> One other possible incompatibility would be with the use of the subst
>>> command. The issue here is whether $(...) would be a command or
>>> variable substitution that subst has options to suppress.
>>>
>>> —-
>>>
>>> Can you explain?
>>>
>>>
>>> —Kevin
>>>
>>> On Oct 22, 2025, at 9:13 PM, EricT <tw...@gm...> wrote:
>>>
>>> 
>>>
>>> Hi Kevin,
>>>
>>> Variable substitution doesn't change at all. $(expr) or $=(expr) is
>>> purely syntactic sugar that transforms to [expr {expr}] before any
>>> substitution happens.
>>>
>>> The flow is:
>>> 1. Parser sees $(5 + $x) or $=(5 + $x)
>>> 2. Transforms it to [expr {5 + $x}] (synthetic)
>>> 3. Normal Tcl substitution and evaluation proceed
>>>
>>> So $(expr) or $=(expr) is just as self-contained as [expr] - it's the
>>> exact same thing underneath, just with cleaner syntax for the common case
>>> of inline expressions.
>>>
>>> The tradeoffs differ slightly by syntax choice:
>>>
>>> $(...): More intuitive (matches shell and jimtcl), but conflicts with
>>> empty array name edge case
>>> $=(...): No conflicts, but affects literal $=( (extremely rare, easily
>>> escaped)
>>>
>>> Both provide: More readable code, auto-braced (safer), less typing
>>>
>>> You can learn more in the README at:
>>> https://github.com/rocketship88/tcl-tip-672-prototype
>>>
>>> Eric
>>>
>>>
>>> On Wed, Oct 22, 2025 at 12:09 PM Kevin Walzer <kw...@co...>
>>> wrote:
>>>
>>>> This will be a hard sale for me. I have yet to fully understand the
>>>> tradeoffs, ie does variable substitution change?  [expr] is ugly but it is
>>>> self-contained.
>>>>
>>>> On Oct 22, 2025, at 2:44 PM, da Silva, Peter J <
>>>> pet...@fl...> wrote:
>>>>
>>>> 
>>>>
>>>> That doesn’t seem any better than “set x [= {$y + 1}]”
>>>>
>>>>
>>>>
>>>> And the Unicode version gives me flashbacks to early Smalltalk and APL.
>>>>
>>>>
>>>>
>>>> I started out in favor of the “$(...)” syntax but this is turning into
>>>> creeping Perlism.
>>>>
>>>>
>>>>
>>>> *From: *Florent Merlet <flo...@gm...>
>>>> *Date: *Wednesday, October 22, 2025 at 13:20
>>>> *To: *Zaumseil René <RZa...@kk...>, tc...@ro... <
>>>> tc...@ro...>
>>>> *Cc: *et...@ro... <et...@ro...>,
>>>> tcl...@li... <Tcl...@li...>
>>>> *Subject: *Re: [TCLCORE] [Ext] Re: TIP 672 Implementation Complete -
>>>> Ready for Sponsorship
>>>>
>>>> Another alternative proposal : set x [($y+1)] It is very readable, easy
>>>> to write, there is eventually a unicode version set x 〖$y+1〗 1 . We
>>>> define a new kind of substitution RULE [7'] Expression substitution : If a
>>>> word contains an open bracket
>>>>
>>>> Another alternative proposal :
>>>>
>>>> set x [($y+1)]
>>>>
>>>> It is very readable, easy to write, there is eventually a unicode
>>>> version
>>>>
>>>> set x 〖$y+1〗
>>>>
>>>> 1 . We define a new kind of substitution
>>>>
>>>> RULE [7'] Expression substitution :
>>>>
>>>> If a word contains an open bracket *« [ »* immediately followed by an
>>>> open parenthesis « ( », then Tcl performs an Expression substitution. To do
>>>> this it invokes the Tcl interpreter recursively to process the characters
>>>> following the open parenthesis as a Tcl mathematical Expression. The
>>>> Expression must be terminated by a close bracket « *] » *immediately preceded
>>>> by a closed parenthesis « ) ». The result of the expression is substituted
>>>> into the word in place of the brackets-parenthesis and all of the
>>>> characters between them. There may be any number of expression
>>>> substitutions in a single word. Expression substitution is not performed on
>>>> words enclosed in braces.
>>>>
>>>> 2. We create the test in ParseToken
>>>>
>>>> ... else if (*src == '[') {
>>>>
>>>>            if (src[1] == '(') {
>>>>
>>>>                      // Expression substitution
>>>>
>>>>                      // must finish by « )] »
>>>>
>>>>                     // doesn't know how to do it...
>>>>
>>>>             } else {
>>>>
>>>>                      // Command substitution
>>>>
>>>>             }
>>>>
>>>> 3. we create a -noexpr switch in the subst command
>>>>
>>>> ....
>>>>
>>>> Examples :
>>>>
>>>> inline expression :  string range "my long sentence" 0 end-[($x+2)]
>>>>
>>>> With native list expr enancement :  .c create rectangle {*}[( $X , $Y,
>>>> $X+100, $Y+100 )]
>>>>
>>>> With multiples instructions enhancement :  set multiexpr [( x = 1; y =
>>>> 2; $x-$y, $y-$x )]
>>>>
>>>> Readable, easy to type, test logically positionned in the C source
>>>> code, no double substitution, avoiding confusion with variable substitution
>>>> : This is the solution !
>>>>
>>>> Florent
>>>>
>>>>
>>>>
>>>> Le 22/10/2025 à 15:52, Zaumseil René a écrit :
>>>>
>>>> And how will this be documented? Imho it should be mentioned in the
>>>> dodecalogue.
>>>>
>>>> Currently the used syntax is only used as array variable and not as
>>>> math command.
>>>>
>>>> I remember the big discussion on {*} syntax here.
>>>>
>>>> Again, is this change really more readable and useable?
>>>>
>>>> Is the benefit worth the additional syntax.
>>>>
>>>> Why not create real benefit with p.e. a multiple set command ala tip
>>>> 674.
>>>>
>>>> Or a new math command without need of $.. access to variables.
>>>>
>>>>
>>>>
>>>> Regards
>>>>
>>>> rene
>>>>
>>>>
>>>>
>>>> *Von:* Florent Merlet <flo...@gm...>
>>>> <flo...@gm...>
>>>> *Gesendet:* Mittwoch, 22. Oktober 2025 15:39
>>>> *An:* tc...@ro...
>>>> *Cc:* et...@ro...; tcl...@li...
>>>> *Betreff:* [Ext] Re: [TCLCORE] TIP 672 Implementation Complete - Ready
>>>> for Sponsorship
>>>>
>>>>
>>>>
>>>> So, everybody in the core team agree with the implementation of a new
>>>> math-Expression substitution as a memlink command into the procedure in
>>>> charge of variable name substitution ?
>>>>
>>>>
>>>>
>>>> Le mer. 22 oct. 2025, 14:07, EricT <tw...@gm...> a écrit :
>>>>
>>>> Hi everyone,
>>>>
>>>> I wanted to update you on the status of TIP 672 (expression
>>>> substitution syntax).
>>>>
>>>> The prototype implementation is now complete and available at:
>>>> https://github.com/rocketship88/tcl-tip-672-prototype
>>>> <https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=ZG5I9vay2CgB9hUAk2I-pkA-6Y6ofRO4-983kuM23Nw&e=>
>>>>
>>>> The implementation has been parameterized to support both discussed
>>>> approaches with a simple compile-time flag:
>>>> - Mode 1: $(expr) syntax
>>>> - Mode 2: $=(expr) or $^(expr) - configurable character
>>>>
>>>> Key features:
>>>> - Comprehensive test suite (82 tests covering edge cases)
>>>> - Minimal code changes (~100 lines)
>>>> - Clean integration with existing parser
>>>> - Full Tcl test suite passes (only 3 expected differences)
>>>>
>>>> There is one known issue: a minor memory leak in the synthetic command
>>>> strings that will need attention during integration.
>>>>
>>>> At this point, I need a sponsor to upload the code to a TIP branch on
>>>> Fossil so the core team can review and decide whether to adopt the TIP and,
>>>> if so, which syntax to use. I'm available for any collaborative work,
>>>> questions, or modifications needed.
>>>>
>>>> I'm grateful for all the feedback and support from the community. I
>>>> look forward to the next steps in the process.
>>>>
>>>> Best regards,
>>>>
>>>> Eric
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Tcl-Core mailing list
>>>> Tcl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>> <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=4iEQfafWSb-GM4h7dq1Qztghg-qOF6HjeF8W3XUHIzs&e=>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>> _______________________________________________
> 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...>]

More examples:

  % set a "\$(1+2)"
$(1+2)

  % set a "$(1+2)"
3

  % set a "a = $(1+2)"
a = 3

  % set a "a = \$(1+2)"
a = $(1+2)

  % string length $(1+2)
1

  % string length \$(1+2)
6

  % string range  \$(1+2) 0 3
$(1+

  % string range  \$(1+2) 0 3+1
$(1+2

  % string range  \$(1+2) 0 3*1
bad index "3*1": must be integer?[+-]integer? or end?[+-]integer?

  % string range  \$(1+2) 0 $(3*1)
$(1+

  % string range  \$(1+2) 0 $(3*2-2)
$(1+2

  % set n 5
5

  % lseq 1 to $($n *2)
1 2 3 4 5 6 7 8 9 10

  % puts $
$

  % puts \$(
$(

 % puts $(
> 5 + 10
> )
15


On Wed, Oct 22, 2025 at 7:12 PM EricT <tw...@gm...> wrote:

> Don:
>
> % set a $(1+2)
> 3
> % set a \$(1+2)
> $(1+2)
>
> Kevin:
>
> In Tcl, array names can be empty strings. So this is valid:
>
> set (index) "value"     # Array with empty name ""
> puts $(index)           # Read from array "" at index "index"
>
> With $(...) syntax for expressions, there's ambiguity:
>
> $(10)                   # Array "" at index "10"? Or an expression
> returning 10?
>
> The parser can't tell which you meant.
>
> The workaround for empty array access:
>
> [set (index)]           # Use [set] command instead of $ substitution
> [set (10)]              # For numeric indices too
>
> 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.
>
> With $=(...), there's no conflict:
>
> $(10)                   # Still array "" at index "10" (no = after $)
> $=(10)                  # Clearly an expression returning 10
>
> That's why some prefer $=(...) - it completely avoids the empty array name
> issue while others prefer the simpler $(...) syntax despite requiring
> migration for the edge case.
>
> The core team would choose which implementation to adopt (not both at the
> same time) should the TIP be approved.
>
> On Wed, Oct 22, 2025 at 6:39 PM Kevin Walzer <kw...@co...> wrote:
>
>> Hi Eric,
>>
>> I’m referring to this section of the TIP:
>>
>> —-
>>
>> One incompatibility is that it would require that the use of the null
>> string "" or {} as an array name would require a change from using $
>> substituion to using the 2 argument form of the set command.
>>
>> Thus, to assign the variable "" to a value, would still work for both
>> scalars and array variables, as in:
>>
>>   set {} foobar             ;# scalar variable
>>   set (index) "array value" ;# array variable
>>
>> But the use of $(index) would have to change by using the set command:
>>
>>   set var [set (index)]
>>
>> One other possible incompatibility would be with the use of the subst
>> command. The issue here is whether $(...) would be a command or variable
>> substitution that subst has options to suppress.
>>
>> —-
>>
>> Can you explain?
>>
>>
>> —Kevin
>>
>> On Oct 22, 2025, at 9:13 PM, EricT <tw...@gm...> wrote:
>>
>> 
>>
>> Hi Kevin,
>>
>> Variable substitution doesn't change at all. $(expr) or $=(expr) is
>> purely syntactic sugar that transforms to [expr {expr}] before any
>> substitution happens.
>>
>> The flow is:
>> 1. Parser sees $(5 + $x) or $=(5 + $x)
>> 2. Transforms it to [expr {5 + $x}] (synthetic)
>> 3. Normal Tcl substitution and evaluation proceed
>>
>> So $(expr) or $=(expr) is just as self-contained as [expr] - it's the
>> exact same thing underneath, just with cleaner syntax for the common case
>> of inline expressions.
>>
>> The tradeoffs differ slightly by syntax choice:
>>
>> $(...): More intuitive (matches shell and jimtcl), but conflicts with
>> empty array name edge case
>> $=(...): No conflicts, but affects literal $=( (extremely rare, easily
>> escaped)
>>
>> Both provide: More readable code, auto-braced (safer), less typing
>>
>> You can learn more in the README at:
>> https://github.com/rocketship88/tcl-tip-672-prototype
>>
>> Eric
>>
>>
>> On Wed, Oct 22, 2025 at 12:09 PM Kevin Walzer <kw...@co...> wrote:
>>
>>> This will be a hard sale for me. I have yet to fully understand the
>>> tradeoffs, ie does variable substitution change?  [expr] is ugly but it is
>>> self-contained.
>>>
>>> On Oct 22, 2025, at 2:44 PM, da Silva, Peter J <
>>> pet...@fl...> wrote:
>>>
>>> 
>>>
>>> That doesn’t seem any better than “set x [= {$y + 1}]”
>>>
>>>
>>>
>>> And the Unicode version gives me flashbacks to early Smalltalk and APL.
>>>
>>>
>>>
>>> I started out in favor of the “$(...)” syntax but this is turning into
>>> creeping Perlism.
>>>
>>>
>>>
>>> *From: *Florent Merlet <flo...@gm...>
>>> *Date: *Wednesday, October 22, 2025 at 13:20
>>> *To: *Zaumseil René <RZa...@kk...>, tc...@ro... <
>>> tc...@ro...>
>>> *Cc: *et...@ro... <et...@ro...>,
>>> tcl...@li... <Tcl...@li...>
>>> *Subject: *Re: [TCLCORE] [Ext] Re: TIP 672 Implementation Complete -
>>> Ready for Sponsorship
>>>
>>> Another alternative proposal : set x [($y+1)] It is very readable, easy
>>> to write, there is eventually a unicode version set x 〖$y+1〗 1 . We
>>> define a new kind of substitution RULE [7'] Expression substitution : If a
>>> word contains an open bracket
>>>
>>> Another alternative proposal :
>>>
>>> set x [($y+1)]
>>>
>>> It is very readable, easy to write, there is eventually a unicode
>>> version
>>>
>>> set x 〖$y+1〗
>>>
>>> 1 . We define a new kind of substitution
>>>
>>> RULE [7'] Expression substitution :
>>>
>>> If a word contains an open bracket *« [ »* immediately followed by an
>>> open parenthesis « ( », then Tcl performs an Expression substitution. To do
>>> this it invokes the Tcl interpreter recursively to process the characters
>>> following the open parenthesis as a Tcl mathematical Expression. The
>>> Expression must be terminated by a close bracket « *] » *immediately preceded
>>> by a closed parenthesis « ) ». The result of the expression is substituted
>>> into the word in place of the brackets-parenthesis and all of the
>>> characters between them. There may be any number of expression
>>> substitutions in a single word. Expression substitution is not performed on
>>> words enclosed in braces.
>>>
>>> 2. We create the test in ParseToken
>>>
>>> ... else if (*src == '[') {
>>>
>>>            if (src[1] == '(') {
>>>
>>>                      // Expression substitution
>>>
>>>                      // must finish by « )] »
>>>
>>>                     // doesn't know how to do it...
>>>
>>>             } else {
>>>
>>>                      // Command substitution
>>>
>>>             }
>>>
>>> 3. we create a -noexpr switch in the subst command
>>>
>>> ....
>>>
>>> Examples :
>>>
>>> inline expression :  string range "my long sentence" 0 end-[($x+2)]
>>>
>>> With native list expr enancement :  .c create rectangle {*}[( $X , $Y,
>>> $X+100, $Y+100 )]
>>>
>>> With multiples instructions enhancement :  set multiexpr [( x = 1; y =
>>> 2; $x-$y, $y-$x )]
>>>
>>> Readable, easy to type, test logically positionned in the C source code,
>>> no double substitution, avoiding confusion with variable substitution :
>>> This is the solution !
>>>
>>> Florent
>>>
>>>
>>>
>>> Le 22/10/2025 à 15:52, Zaumseil René a écrit :
>>>
>>> And how will this be documented? Imho it should be mentioned in the
>>> dodecalogue.
>>>
>>> Currently the used syntax is only used as array variable and not as math
>>> command.
>>>
>>> I remember the big discussion on {*} syntax here.
>>>
>>> Again, is this change really more readable and useable?
>>>
>>> Is the benefit worth the additional syntax.
>>>
>>> Why not create real benefit with p.e. a multiple set command ala tip 674.
>>>
>>> Or a new math command without need of $.. access to variables.
>>>
>>>
>>>
>>> Regards
>>>
>>> rene
>>>
>>>
>>>
>>> *Von:* Florent Merlet <flo...@gm...>
>>> <flo...@gm...>
>>> *Gesendet:* Mittwoch, 22. Oktober 2025 15:39
>>> *An:* tc...@ro...
>>> *Cc:* et...@ro...; tcl...@li...
>>> *Betreff:* [Ext] Re: [TCLCORE] TIP 672 Implementation Complete - Ready
>>> for Sponsorship
>>>
>>>
>>>
>>> So, everybody in the core team agree with the implementation of a new
>>> math-Expression substitution as a memlink command into the procedure in
>>> charge of variable name substitution ?
>>>
>>>
>>>
>>> Le mer. 22 oct. 2025, 14:07, EricT <tw...@gm...> a écrit :
>>>
>>> Hi everyone,
>>>
>>> I wanted to update you on the status of TIP 672 (expression substitution
>>> syntax).
>>>
>>> The prototype implementation is now complete and available at:
>>> https://github.com/rocketship88/tcl-tip-672-prototype
>>> <https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=ZG5I9vay2CgB9hUAk2I-pkA-6Y6ofRO4-983kuM23Nw&e=>
>>>
>>> The implementation has been parameterized to support both discussed
>>> approaches with a simple compile-time flag:
>>> - Mode 1: $(expr) syntax
>>> - Mode 2: $=(expr) or $^(expr) - configurable character
>>>
>>> Key features:
>>> - Comprehensive test suite (82 tests covering edge cases)
>>> - Minimal code changes (~100 lines)
>>> - Clean integration with existing parser
>>> - Full Tcl test suite passes (only 3 expected differences)
>>>
>>> There is one known issue: a minor memory leak in the synthetic command
>>> strings that will need attention during integration.
>>>
>>> At this point, I need a sponsor to upload the code to a TIP branch on
>>> Fossil so the core team can review and decide whether to adopt the TIP and,
>>> if so, which syntax to use. I'm available for any collaborative work,
>>> questions, or modifications needed.
>>>
>>> I'm grateful for all the feedback and support from the community. I look
>>> forward to the next steps in the process.
>>>
>>> Best regards,
>>>
>>> Eric
>>>
>>>
>>>
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>> <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=4iEQfafWSb-GM4h7dq1Qztghg-qOF6HjeF8W3XUHIzs&e=>
>>>
>>> _______________________________________________
>>> 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...>]

Don:

% set a $(1+2)
3
% set a \$(1+2)
$(1+2)

Kevin:

In Tcl, array names can be empty strings. So this is valid:

set (index) "value"     # Array with empty name ""
puts $(index)           # Read from array "" at index "index"

With $(...) syntax for expressions, there's ambiguity:

$(10)                   # Array "" at index "10"? Or an expression
returning 10?

The parser can't tell which you meant.

The workaround for empty array access:

[set (index)]           # Use [set] command instead of $ substitution
[set (10)]              # For numeric indices too

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.

With $=(...), there's no conflict:

$(10)                   # Still array "" at index "10" (no = after $)
$=(10)                  # Clearly an expression returning 10

That's why some prefer $=(...) - it completely avoids the empty array name
issue while others prefer the simpler $(...) syntax despite requiring
migration for the edge case.

The core team would choose which implementation to adopt (not both at the
same time) should the TIP be approved.

On Wed, Oct 22, 2025 at 6:39 PM Kevin Walzer <kw...@co...> wrote:

> Hi Eric,
>
> I’m referring to this section of the TIP:
>
> —-
>
> One incompatibility is that it would require that the use of the null
> string "" or {} as an array name would require a change from using $
> substituion to using the 2 argument form of the set command.
>
> Thus, to assign the variable "" to a value, would still work for both
> scalars and array variables, as in:
>
>   set {} foobar             ;# scalar variable
>   set (index) "array value" ;# array variable
>
> But the use of $(index) would have to change by using the set command:
>
>   set var [set (index)]
>
> One other possible incompatibility would be with the use of the subst
> command. The issue here is whether $(...) would be a command or variable
> substitution that subst has options to suppress.
>
> —-
>
> Can you explain?
>
>
> —Kevin
>
> On Oct 22, 2025, at 9:13 PM, EricT <tw...@gm...> wrote:
>
> 
>
> Hi Kevin,
>
> Variable substitution doesn't change at all. $(expr) or $=(expr) is purely
> syntactic sugar that transforms to [expr {expr}] before any substitution
> happens.
>
> The flow is:
> 1. Parser sees $(5 + $x) or $=(5 + $x)
> 2. Transforms it to [expr {5 + $x}] (synthetic)
> 3. Normal Tcl substitution and evaluation proceed
>
> So $(expr) or $=(expr) is just as self-contained as [expr] - it's the
> exact same thing underneath, just with cleaner syntax for the common case
> of inline expressions.
>
> The tradeoffs differ slightly by syntax choice:
>
> $(...): More intuitive (matches shell and jimtcl), but conflicts with
> empty array name edge case
> $=(...): No conflicts, but affects literal $=( (extremely rare, easily
> escaped)
>
> Both provide: More readable code, auto-braced (safer), less typing
>
> You can learn more in the README at:
> https://github.com/rocketship88/tcl-tip-672-prototype
>
> Eric
>
>
> On Wed, Oct 22, 2025 at 12:09 PM Kevin Walzer <kw...@co...> wrote:
>
>> This will be a hard sale for me. I have yet to fully understand the
>> tradeoffs, ie does variable substitution change?  [expr] is ugly but it is
>> self-contained.
>>
>> On Oct 22, 2025, at 2:44 PM, da Silva, Peter J <
>> pet...@fl...> wrote:
>>
>> 
>>
>> That doesn’t seem any better than “set x [= {$y + 1}]”
>>
>>
>>
>> And the Unicode version gives me flashbacks to early Smalltalk and APL.
>>
>>
>>
>> I started out in favor of the “$(...)” syntax but this is turning into
>> creeping Perlism.
>>
>>
>>
>> *From: *Florent Merlet <flo...@gm...>
>> *Date: *Wednesday, October 22, 2025 at 13:20
>> *To: *Zaumseil René <RZa...@kk...>, tc...@ro... <
>> tc...@ro...>
>> *Cc: *et...@ro... <et...@ro...>,
>> tcl...@li... <Tcl...@li...>
>> *Subject: *Re: [TCLCORE] [Ext] Re: TIP 672 Implementation Complete -
>> Ready for Sponsorship
>>
>> Another alternative proposal : set x [($y+1)] It is very readable, easy
>> to write, there is eventually a unicode version set x 〖$y+1〗 1 . We
>> define a new kind of substitution RULE [7'] Expression substitution : If a
>> word contains an open bracket
>>
>> Another alternative proposal :
>>
>> set x [($y+1)]
>>
>> It is very readable, easy to write, there is eventually a unicode version
>>
>> set x 〖$y+1〗
>>
>> 1 . We define a new kind of substitution
>>
>> RULE [7'] Expression substitution :
>>
>> If a word contains an open bracket *« [ »* immediately followed by an
>> open parenthesis « ( », then Tcl performs an Expression substitution. To do
>> this it invokes the Tcl interpreter recursively to process the characters
>> following the open parenthesis as a Tcl mathematical Expression. The
>> Expression must be terminated by a close bracket « *] » *immediately preceded
>> by a closed parenthesis « ) ». The result of the expression is substituted
>> into the word in place of the brackets-parenthesis and all of the
>> characters between them. There may be any number of expression
>> substitutions in a single word. Expression substitution is not performed on
>> words enclosed in braces.
>>
>> 2. We create the test in ParseToken
>>
>> ... else if (*src == '[') {
>>
>>            if (src[1] == '(') {
>>
>>                      // Expression substitution
>>
>>                      // must finish by « )] »
>>
>>                     // doesn't know how to do it...
>>
>>             } else {
>>
>>                      // Command substitution
>>
>>             }
>>
>> 3. we create a -noexpr switch in the subst command
>>
>> ....
>>
>> Examples :
>>
>> inline expression :  string range "my long sentence" 0 end-[($x+2)]
>>
>> With native list expr enancement :  .c create rectangle {*}[( $X , $Y,
>> $X+100, $Y+100 )]
>>
>> With multiples instructions enhancement :  set multiexpr [( x = 1; y = 2;
>> $x-$y, $y-$x )]
>>
>> Readable, easy to type, test logically positionned in the C source code,
>> no double substitution, avoiding confusion with variable substitution :
>> This is the solution !
>>
>> Florent
>>
>>
>>
>> Le 22/10/2025 à 15:52, Zaumseil René a écrit :
>>
>> And how will this be documented? Imho it should be mentioned in the
>> dodecalogue.
>>
>> Currently the used syntax is only used as array variable and not as math
>> command.
>>
>> I remember the big discussion on {*} syntax here.
>>
>> Again, is this change really more readable and useable?
>>
>> Is the benefit worth the additional syntax.
>>
>> Why not create real benefit with p.e. a multiple set command ala tip 674.
>>
>> Or a new math command without need of $.. access to variables.
>>
>>
>>
>> Regards
>>
>> rene
>>
>>
>>
>> *Von:* Florent Merlet <flo...@gm...>
>> <flo...@gm...>
>> *Gesendet:* Mittwoch, 22. Oktober 2025 15:39
>> *An:* tc...@ro...
>> *Cc:* et...@ro...; tcl...@li...
>> *Betreff:* [Ext] Re: [TCLCORE] TIP 672 Implementation Complete - Ready
>> for Sponsorship
>>
>>
>>
>> So, everybody in the core team agree with the implementation of a new
>> math-Expression substitution as a memlink command into the procedure in
>> charge of variable name substitution ?
>>
>>
>>
>> Le mer. 22 oct. 2025, 14:07, EricT <tw...@gm...> a écrit :
>>
>> Hi everyone,
>>
>> I wanted to update you on the status of TIP 672 (expression substitution
>> syntax).
>>
>> The prototype implementation is now complete and available at:
>> https://github.com/rocketship88/tcl-tip-672-prototype
>> <https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=ZG5I9vay2CgB9hUAk2I-pkA-6Y6ofRO4-983kuM23Nw&e=>
>>
>> The implementation has been parameterized to support both discussed
>> approaches with a simple compile-time flag:
>> - Mode 1: $(expr) syntax
>> - Mode 2: $=(expr) or $^(expr) - configurable character
>>
>> Key features:
>> - Comprehensive test suite (82 tests covering edge cases)
>> - Minimal code changes (~100 lines)
>> - Clean integration with existing parser
>> - Full Tcl test suite passes (only 3 expected differences)
>>
>> There is one known issue: a minor memory leak in the synthetic command
>> strings that will need attention during integration.
>>
>> At this point, I need a sponsor to upload the code to a TIP branch on
>> Fossil so the core team can review and decide whether to adopt the TIP and,
>> if so, which syntax to use. I'm available for any collaborative work,
>> questions, or modifications needed.
>>
>> I'm grateful for all the feedback and support from the community. I look
>> forward to the next steps in the process.
>>
>> Best regards,
>>
>> Eric
>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>> <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=4iEQfafWSb-GM4h7dq1Qztghg-qOF6HjeF8W3XUHIzs&e=>
>>
>> _______________________________________________
>> 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

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

> 1. Parser sees $(5 + $x) or $=(5 + $x)
> 2. Transforms it to [expr {5 + $x}] (synthetic)
> 3. Normal Tcl substitution and evaluation proceed

Reading this gives me doubts.

Are we sure this approach always preserves the distinct environments […] and “…” and {…} regarding when substitution takes place and when it is suppressed?

(I have been assuming this new substitution mode would be enabled / disabled in the same manner as other substitution modes).

Every substitution syntax must have a corresponding syntax that “escapes” or disables it.  The existing ones use a preceding backslash to escape the substitution.  Is that true of the proposed substitution syntaxes as well?

DGP

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

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Hi Eric,</div><div dir="ltr"><br></div><div dir="ltr">I’m referring to this section of the TIP:</div><div dir="ltr"><br></div><div dir="ltr">—-</div><div dir="ltr"><p style="caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-family: sans-serif; font-size: 14.933332px;">One incompatibility is that it would require that the use of the null string&nbsp;<code style="font-family: &quot;Source Code Pro&quot;, Menlo, Monaco, Consolas, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, &quot;Deja Vu Sans Mono&quot;, &quot;Letter Gothic&quot;, &quot;Letter Gothic Std&quot;, &quot;Prestige Elite Std&quot;, Courier, &quot;Courier New&quot;, monospace; white-space: pre-wrap;">""</code>&nbsp;or&nbsp;<code style="font-family: &quot;Source Code Pro&quot;, Menlo, Monaco, Consolas, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, &quot;Deja Vu Sans Mono&quot;, &quot;Letter Gothic&quot;, &quot;Letter Gothic Std&quot;, &quot;Prestige Elite Std&quot;, Courier, &quot;Courier New&quot;, monospace; white-space: pre-wrap;">{}</code>&nbsp;as an array name would require a change from using $ substituion to using the 2 argument form of the set command.</p><p style="caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-family: sans-serif; font-size: 14.933332px;">Thus, to assign the variable&nbsp;<code style="font-family: &quot;Source Code Pro&quot;, Menlo, Monaco, Consolas, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, &quot;Deja Vu Sans Mono&quot;, &quot;Letter Gothic&quot;, &quot;Letter Gothic Std&quot;, &quot;Prestige Elite Std&quot;, Courier, &quot;Courier New&quot;, monospace; white-space: pre-wrap;">""</code>&nbsp;to a value, would still work for both scalars and array variables, as in:</p><pre style="font-family: &quot;Source Code Pro&quot;, Menlo, Monaco, Consolas, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, &quot;Deja Vu Sans Mono&quot;, &quot;Letter Gothic&quot;, &quot;Letter Gothic Std&quot;, &quot;Prestige Elite Std&quot;, Courier, &quot;Courier New&quot;, monospace; caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-size: 14.933332px;"><code style="font-family: &quot;Source Code Pro&quot;, Menlo, Monaco, Consolas, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, &quot;Deja Vu Sans Mono&quot;, &quot;Letter Gothic&quot;, &quot;Letter Gothic Std&quot;, &quot;Prestige Elite Std&quot;, Courier, &quot;Courier New&quot;, monospace;">  set {} foobar             ;# scalar variable
  set (index) "array value" ;# array variable
</code></pre><span style="caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-family: sans-serif; font-size: 14.933332px; background-color: rgb(255, 255, 255);">But the use of&nbsp;</span><code style="white-space: pre-wrap; font-family: &quot;Source Code Pro&quot;, Menlo, Monaco, Consolas, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, &quot;Deja Vu Sans Mono&quot;, &quot;Letter Gothic&quot;, &quot;Letter Gothic Std&quot;, &quot;Prestige Elite Std&quot;, Courier, &quot;Courier New&quot;, monospace; caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-size: 14.933332px;">$(index)</code><span style="caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-family: sans-serif; font-size: 14.933332px; background-color: rgb(255, 255, 255);">&nbsp;would have to change by using the set command:</span><p style="caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-family: sans-serif; font-size: 14.933332px;"></p><pre style="font-family: &quot;Source Code Pro&quot;, Menlo, Monaco, Consolas, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, &quot;Deja Vu Sans Mono&quot;, &quot;Letter Gothic&quot;, &quot;Letter Gothic Std&quot;, &quot;Prestige Elite Std&quot;, Courier, &quot;Courier New&quot;, monospace; caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-size: 14.933332px;"><code style="font-family: &quot;Source Code Pro&quot;, Menlo, Monaco, Consolas, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, &quot;Deja Vu Sans Mono&quot;, &quot;Letter Gothic&quot;, &quot;Letter Gothic Std&quot;, &quot;Prestige Elite Std&quot;, Courier, &quot;Courier New&quot;, monospace;">  set var [set (index)]
</code></pre><p style="caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-family: sans-serif; font-size: 14.933332px;">One other possible incompatibility would be with the use of the subst command. The issue here is whether&nbsp;<code style="font-family: &quot;Source Code Pro&quot;, Menlo, Monaco, Consolas, &quot;Andale Mono&quot;, &quot;Ubuntu Mono&quot;, &quot;Deja Vu Sans Mono&quot;, &quot;Letter Gothic&quot;, &quot;Letter Gothic Std&quot;, &quot;Prestige Elite Std&quot;, Courier, &quot;Courier New&quot;, monospace; white-space: pre-wrap;">$(...)</code>&nbsp;would be a command or variable substitution that subst has options to suppress.</p><p style="caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-family: sans-serif; font-size: 14.933332px;">—-</p><p style="caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-family: sans-serif; font-size: 14.933332px;">Can you explain?</p><p style="caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-family: sans-serif; font-size: 14.933332px;"><br></p><p style="caret-color: rgb(68, 68, 68); color: rgb(68, 68, 68); font-family: sans-serif; font-size: 14.933332px;">—Kevin</p></div><div dir="ltr"><br><blockquote type="cite">On Oct 22, 2025, at 9:13 PM, EricT &lt;tw...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><br>Hi Kevin,<br><br>Variable substitution doesn't change at all. $(expr) or $=(expr) is purely syntactic sugar that transforms to [expr {expr}] before any substitution happens.<br><br>The flow is:<br>1. Parser sees $(5 + $x) or $=(5 + $x)<br>2. Transforms it to [expr {5 + $x}] (synthetic)<br>3. Normal Tcl substitution and evaluation proceed<br><br>So $(expr) or $=(expr) is just as self-contained as [expr] - it's the exact same thing underneath, just with cleaner syntax for the common case of inline expressions.<br><br>The tradeoffs differ slightly by syntax choice:<br><br>$(...): More intuitive (matches shell and jimtcl), but conflicts with empty array name edge case<br>$=(...): No conflicts, but affects literal $=( (extremely rare, easily escaped)<br><br>Both provide: More readable code, auto-braced (safer), less typing<br><br>You can learn more in the README at:<br><a href="https://github.com/rocketship88/tcl-tip-672-prototype">https://github.com/rocketship88/tcl-tip-672-prototype</a><br><div><br></div><div>Eric</div><div><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Oct 22, 2025 at 12:09 PM Kevin Walzer &lt;<a href="mailto:kw...@co...">kw...@co...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">This will be a hard sale for me. I have yet to fully understand the tradeoffs, ie does variable substitution change? &nbsp;[expr] is ugly but it is self-contained. &nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Oct 22, 2025, at 2:44 PM, da Silva, Peter J &lt;<a href="mailto:pet...@fl..." target="_blank">pet...@fl...</a>&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">






<div>
<p class="MsoNormal"><span style="font-size:11pt">That doesn’t seem any better than “set x [= {$y + 1}]”<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u>&nbsp;<u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">And the Unicode version gives me flashbacks to early Smalltalk and APL.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u>&nbsp;<u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt">I started out in favor of the “$(...)” syntax but this is turning into creeping Perlism.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt"><u></u>&nbsp;<u></u></span></p>
<div id="m_-6858449944373502036mail-editor-reference-message-container">
<div>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(181,196,223) currentcolor currentcolor;padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="color:black">From:
</span></b><span style="color:black">Florent Merlet &lt;<a href="mailto:flo...@gm..." target="_blank">flo...@gm...</a>&gt;<br>
<b>Date: </b>Wednesday, October 22, 2025 at 13:20<br>
<b>To: </b>Zaumseil René &lt;<a href="mailto:RZa...@kk..." target="_blank">RZa...@kk...</a>&gt;, <a href="mailto:tc...@ro..." target="_blank">tc...@ro...</a> &lt;<a href="mailto:tc...@ro..." target="_blank">tc...@ro...</a>&gt;<br>
<b>Cc: </b><a href="mailto:et...@ro..." target="_blank">et...@ro...</a> &lt;<a href="mailto:et...@ro..." target="_blank">et...@ro...</a>&gt;, <a href="mailto:tcl...@li..." target="_blank">tcl...@li...</a> &lt;<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a>&gt;<br>
<b>Subject: </b>Re: [TCLCORE] [Ext] Re: TIP 672 Implementation Complete - Ready for Sponsorship<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:1pt;color:white">Another alternative proposal : set x [($y+1)] It is very readable, easy to write, there is eventually a unicode version set x
</span><span style="font-size:1pt;font-family:&quot;Cambria Math&quot;,serif;color:white">〖</span><span style="font-size:1pt;color:white">$y+1</span><span style="font-size:1pt;font-family:&quot;Cambria Math&quot;,serif;color:white">〗</span><span style="font-size:1pt;color:white">
 1 . We define a new kind of substitution RULE [7'] Expression substitution : If a word contains an open bracket<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:1pt;color:white"><u></u><u></u></span></p>
</div>
<p>Another alternative proposal :&nbsp;<u></u><u></u></p>
<p>set x [($y+1)]<u></u><u></u></p>
<p>It is very readable, easy to write,&nbsp;there is eventually a unicode version&nbsp;<u></u><u></u></p>
<p><span>set x </span><span><span style="font-family:&quot;Cambria Math&quot;,serif">〖</span>$y+1</span><span><span style="font-family:&quot;Cambria Math&quot;,serif">〗</span></span><u></u><u></u></p>
<p>1 . We define a new kind of substitution<u></u><u></u></p>
<p>RULE [7'] Expression substitution :<u></u><u></u></p>
<p>If a word contains an open bracket <b>«<span>&nbsp;[ »</span></b>&nbsp;immediately followed by an open parenthesis « ( », then Tcl performs an Expression substitution. To do this it invokes the Tcl interpreter recursively to process the characters following
 the open parenthesis as a Tcl mathematical Expression. The Expression must be terminated by a close bracket «&nbsp;<span><b>] »&nbsp;</b></span>immediately&nbsp;preceded by a closed parenthesis « ) ». The result of the expression is substituted into the word
 in place of the brackets-parenthesis and all of the characters between them. There may be any number of expression substitutions in a single word. Expression substitution is not performed on words enclosed in braces.<u></u><u></u></p>
<p>2. We create the test in ParseToken<u></u><u></u></p>
<p>... else if (*src == '[') {<u></u><u></u></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (src[1] == '(') {<u></u><u></u></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Expression substitution<u></u><u></u></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// must finish by « )] »<u></u><u></u></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; // doesn't know how to do it...&nbsp;<u></u><u></u></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; } else {<u></u><u></u></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Command substitution<u></u><u></u></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }<u></u><u></u></p>
<p>3. we create a -noexpr switch in the subst command<u></u><u></u></p>
<p>....<u></u><u></u></p>
<p>Examples :<u></u><u></u></p>
<p>inline expression :&nbsp;&nbsp;string range "my long sentence" 0 end-[($x+2)]<u></u><u></u></p>
<p>With native list expr enancement :&nbsp;&nbsp;.c create rectangle {*}[( $X , $Y, $X+100, $Y+100 )]<u></u><u></u></p>
<p>With multiples instructions enhancement :&nbsp;&nbsp;set multiexpr [( x = 1; y = 2; $x-$y, $y-$x )]<u></u><u></u></p>
<p>Readable, easy to type, test logically positionned in the C source code, no double substitution, avoiding confusion with variable substitution : This is the solution !<u></u><u></u></p>
<p>Florent<u></u><u></u></p>
<p><u></u>&nbsp;<u></u></p>
<div>
<p class="MsoNormal">Le 22/10/2025 à 15:52, Zaumseil René a écrit&nbsp;:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">And how will this be documented? Imho it should be mentioned in the dodecalogue.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Currently the used syntax is only used as array variable and not as math command.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">I remember the big discussion on {*} syntax here.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Again, is this change really more readable and useable?</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Is the benefit worth the additional syntax.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Why not create real benefit with p.e. a multiple set command ala tip 674.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Or a new math command without need of $.. access to variables.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">&nbsp;</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Regards</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">rene</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">&nbsp;</span><u></u><u></u></p>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0in 0in">
<p class="MsoNormal"><b><span lang="DE" style="font-size:11pt;font-family:&quot;Calibri&quot;,sans-serif">Von:</span></b><span lang="DE" style="font-size:11pt;font-family:&quot;Calibri&quot;,sans-serif"> Florent Merlet
<a href="mailto:flo...@gm..." target="_blank">&lt;flo...@gm...&gt;</a> <br>
<b>Gesendet:</b> Mittwoch, 22. Oktober 2025 15:39<br>
<b>An:</b> <a href="mailto:tc...@ro..." target="_blank">tc...@ro...</a><br>
<b>Cc:</b> <a href="mailto:et...@ro..." target="_blank">et...@ro...</a>; <a href="mailto:tcl...@li..." target="_blank">
tcl...@li...</a><br>
<b>Betreff:</b> [Ext] Re: [TCLCORE] TIP 672 Implementation Complete - Ready for Sponsorship</span><u></u><u></u></p>
</div>
<p class="MsoNormal">&nbsp;<u></u><u></u></p>
<div>
<p class="MsoNormal">So, everybody in the core team agree with the implementation of a new math-Expression substitution as a memlink command into the procedure in charge of variable name substitution ?&nbsp;<u></u><u></u></p>
</div>
<p class="MsoNormal">&nbsp;<u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Le mer. 22 oct. 2025, 14:07, EricT &lt;<a href="mailto:tw...@gm..." target="_blank">tw...@gm...</a>&gt; a écrit&nbsp;:<u></u><u></u></p>
</div>
<blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<p class="MsoNormal">Hi everyone,<br>
<br>
I wanted to update you on the status of TIP 672 (expression substitution syntax).<br>
<br>
The prototype implementation is now complete and available at:<br>
<a href="https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&amp;d=DwMDaQ&amp;c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&amp;r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&amp;m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&amp;s=ZG5I9vay2CgB9hUAk2I-pkA-6Y6ofRO4-983kuM23Nw&amp;e=" target="_blank">https://github.com/rocketship88/tcl-tip-672-prototype</a><br>
<br>
The implementation has been parameterized to support both discussed approaches with a simple compile-time flag:<br>
- Mode 1: $(expr) syntax<br>
- Mode 2: $=(expr) or $^(expr) - configurable character<br>
<br>
Key features:<br>
- Comprehensive test suite (82 tests covering edge cases)<br>
- Minimal code changes (~100 lines)<br>
- Clean integration with existing parser<br>
- Full Tcl test suite passes (only 3 expected differences)<br>
<br>
There is one known issue: a minor memory leak in the synthetic command strings that will need attention during integration.<br>
<br>
At this point, I need a sponsor to upload the code to a TIP branch on Fossil so the core team can review and decide whether to adopt the TIP and, if so, which syntax to use. I'm available for any collaborative work, questions, or modifications needed.<br>
<br>
I'm grateful for all the feedback and support from the community. I look forward to the next steps in the process.<br>
<br>
Best regards,<u></u><u></u></p>
<div>
<p class="MsoNormal">Eric<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">&nbsp;<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Tcl-Core mailing list<br>
<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br>
<a href="https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&amp;d=DwMDaQ&amp;c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&amp;r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&amp;m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&amp;s=4iEQfafWSb-GM4h7dq1Qztghg-qOF6HjeF8W3XUHIzs&amp;e=" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><u></u><u></u></p>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>


<span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span><a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a></span><br><span><a href="https://lists.sourceforge.net/lists/listinfo/tcl-core" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a></span><br></div></blockquote></div>_______________________________________________<br>
Tcl-Core mailing list<br>
<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/tcl-core" rel="noreferrer" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><br>
</blockquote></div>
</div></blockquote></body></html>

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

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

Hi Kevin,

Variable substitution doesn't change at all. $(expr) or $=(expr) is purely
syntactic sugar that transforms to [expr {expr}] before any substitution
happens.

The flow is:
1. Parser sees $(5 + $x) or $=(5 + $x)
2. Transforms it to [expr {5 + $x}] (synthetic)
3. Normal Tcl substitution and evaluation proceed

So $(expr) or $=(expr) is just as self-contained as [expr] - it's the exact
same thing underneath, just with cleaner syntax for the common case of
inline expressions.

The tradeoffs differ slightly by syntax choice:

$(...): More intuitive (matches shell and jimtcl), but conflicts with empty
array name edge case
$=(...): No conflicts, but affects literal $=( (extremely rare, easily
escaped)

Both provide: More readable code, auto-braced (safer), less typing

You can learn more in the README at:
https://github.com/rocketship88/tcl-tip-672-prototype

Eric


On Wed, Oct 22, 2025 at 12:09 PM Kevin Walzer <kw...@co...> wrote:

> This will be a hard sale for me. I have yet to fully understand the
> tradeoffs, ie does variable substitution change?  [expr] is ugly but it is
> self-contained.
>
> On Oct 22, 2025, at 2:44 PM, da Silva, Peter J <
> pet...@fl...> wrote:
>
> 
>
> That doesn’t seem any better than “set x [= {$y + 1}]”
>
>
>
> And the Unicode version gives me flashbacks to early Smalltalk and APL.
>
>
>
> I started out in favor of the “$(...)” syntax but this is turning into
> creeping Perlism.
>
>
>
> *From: *Florent Merlet <flo...@gm...>
> *Date: *Wednesday, October 22, 2025 at 13:20
> *To: *Zaumseil René <RZa...@kk...>, tc...@ro... <
> tc...@ro...>
> *Cc: *et...@ro... <et...@ro...>,
> tcl...@li... <Tcl...@li...>
> *Subject: *Re: [TCLCORE] [Ext] Re: TIP 672 Implementation Complete -
> Ready for Sponsorship
>
> Another alternative proposal : set x [($y+1)] It is very readable, easy to
> write, there is eventually a unicode version set x 〖$y+1〗 1 . We define a
> new kind of substitution RULE [7'] Expression substitution : If a word
> contains an open bracket
>
> Another alternative proposal :
>
> set x [($y+1)]
>
> It is very readable, easy to write, there is eventually a unicode version
>
> set x 〖$y+1〗
>
> 1 . We define a new kind of substitution
>
> RULE [7'] Expression substitution :
>
> If a word contains an open bracket *« [ »* immediately followed by an
> open parenthesis « ( », then Tcl performs an Expression substitution. To do
> this it invokes the Tcl interpreter recursively to process the characters
> following the open parenthesis as a Tcl mathematical Expression. The
> Expression must be terminated by a close bracket « *] » *immediately preceded
> by a closed parenthesis « ) ». The result of the expression is substituted
> into the word in place of the brackets-parenthesis and all of the
> characters between them. There may be any number of expression
> substitutions in a single word. Expression substitution is not performed on
> words enclosed in braces.
>
> 2. We create the test in ParseToken
>
> ... else if (*src == '[') {
>
>            if (src[1] == '(') {
>
>                      // Expression substitution
>
>                      // must finish by « )] »
>
>                     // doesn't know how to do it...
>
>             } else {
>
>                      // Command substitution
>
>             }
>
> 3. we create a -noexpr switch in the subst command
>
> ....
>
> Examples :
>
> inline expression :  string range "my long sentence" 0 end-[($x+2)]
>
> With native list expr enancement :  .c create rectangle {*}[( $X , $Y,
> $X+100, $Y+100 )]
>
> With multiples instructions enhancement :  set multiexpr [( x = 1; y = 2;
> $x-$y, $y-$x )]
>
> Readable, easy to type, test logically positionned in the C source code,
> no double substitution, avoiding confusion with variable substitution :
> This is the solution !
>
> Florent
>
>
>
> Le 22/10/2025 à 15:52, Zaumseil René a écrit :
>
> And how will this be documented? Imho it should be mentioned in the
> dodecalogue.
>
> Currently the used syntax is only used as array variable and not as math
> command.
>
> I remember the big discussion on {*} syntax here.
>
> Again, is this change really more readable and useable?
>
> Is the benefit worth the additional syntax.
>
> Why not create real benefit with p.e. a multiple set command ala tip 674.
>
> Or a new math command without need of $.. access to variables.
>
>
>
> Regards
>
> rene
>
>
>
> *Von:* Florent Merlet <flo...@gm...>
> <flo...@gm...>
> *Gesendet:* Mittwoch, 22. Oktober 2025 15:39
> *An:* tc...@ro...
> *Cc:* et...@ro...; tcl...@li...
> *Betreff:* [Ext] Re: [TCLCORE] TIP 672 Implementation Complete - Ready
> for Sponsorship
>
>
>
> So, everybody in the core team agree with the implementation of a new
> math-Expression substitution as a memlink command into the procedure in
> charge of variable name substitution ?
>
>
>
> Le mer. 22 oct. 2025, 14:07, EricT <tw...@gm...> a écrit :
>
> Hi everyone,
>
> I wanted to update you on the status of TIP 672 (expression substitution
> syntax).
>
> The prototype implementation is now complete and available at:
> https://github.com/rocketship88/tcl-tip-672-prototype
> <https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=ZG5I9vay2CgB9hUAk2I-pkA-6Y6ofRO4-983kuM23Nw&e=>
>
> The implementation has been parameterized to support both discussed
> approaches with a simple compile-time flag:
> - Mode 1: $(expr) syntax
> - Mode 2: $=(expr) or $^(expr) - configurable character
>
> Key features:
> - Comprehensive test suite (82 tests covering edge cases)
> - Minimal code changes (~100 lines)
> - Clean integration with existing parser
> - Full Tcl test suite passes (only 3 expected differences)
>
> There is one known issue: a minor memory leak in the synthetic command
> strings that will need attention during integration.
>
> At this point, I need a sponsor to upload the code to a TIP branch on
> Fossil so the core team can review and decide whether to adopt the TIP and,
> if so, which syntax to use. I'm available for any collaborative work,
> questions, or modifications needed.
>
> I'm grateful for all the feedback and support from the community. I look
> forward to the next steps in the process.
>
> Best regards,
>
> Eric
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=4iEQfafWSb-GM4h7dq1Qztghg-qOF6HjeF8W3XUHIzs&e=>
>
> _______________________________________________
> 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

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

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">This will be a hard sale for me. I have yet to fully understand the tradeoffs, ie does variable substitution change? &nbsp;[expr] is ugly but it is self-contained. &nbsp;</div><div dir="ltr"><br><blockquote type="cite">On Oct 22, 2025, at 2:44 PM, da Silva, Peter J &lt;pet...@fl...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style>@font-face { font-family: "Cambria Math"; }
@font-face { font-family: Calibri; }
@font-face { font-family: Aptos; }
p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif; }
a:link, span.MsoHyperlink { color: blue; text-decoration: underline; }
span.unicodexl { }
span.mkuptt { }
span.EmailStyle23 { font-family: Aptos, sans-serif; color: windowtext; }
.MsoChpDefault { font-size: 10pt; }
@page WordSection1 { size: 8.5in 11in; margin: 1in; }
div.WordSection1 { page: WordSection1; }</style>


<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">That doesn’t seem any better than “set x [= {$y + 1}]”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">And the Unicode version gives me flashbacks to early Smalltalk and APL.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I started out in favor of the “$(...)” syntax but this is turning into creeping Perlism.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p>&nbsp;</o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="color:black">From:
</span></b><span style="color:black">Florent Merlet &lt;flo...@gm...&gt;<br>
<b>Date: </b>Wednesday, October 22, 2025 at 13:20<br>
<b>To: </b>Zaumseil René &lt;RZa...@kk...&gt;, tc...@ro... &lt;tc...@ro...&gt;<br>
<b>Cc: </b>et...@ro... &lt;et...@ro...&gt;, tcl...@li... &lt;Tcl...@li...&gt;<br>
<b>Subject: </b>Re: [TCLCORE] [Ext] Re: TIP 672 Implementation Complete - Ready for Sponsorship<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-line-height-alt:.75pt"><span style="font-size:1.0pt;color:white">Another alternative proposal : set x [($y+1)] It is very readable, easy to write, there is eventually a unicode version set x
</span><span style="font-size:1.0pt;font-family:&quot;Cambria Math&quot;,serif;color:white">〖</span><span style="font-size:1.0pt;color:white">$y+1</span><span style="font-size:1.0pt;font-family:&quot;Cambria Math&quot;,serif;color:white">〗</span><span style="font-size:1.0pt;color:white">
 1 . We define a new kind of substitution RULE [7'] Expression substitution : If a word contains an open bracket<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="mso-line-height-alt:.75pt"><span style="font-size:1.0pt;color:white"><o:p></o:p></span></p>
</div>
<p>Another alternative proposal :&nbsp;<o:p></o:p></p>
<p>set x [($y+1)]<o:p></o:p></p>
<p>It is very readable, easy to write,&nbsp;there is eventually a unicode version&nbsp;<o:p></o:p></p>
<p><span class="unicodexl">set x </span><span class="unicodexl"><span style="font-family:&quot;Cambria Math&quot;,serif">〖</span>$y+1</span><span class="unicodexl"><span style="font-family:&quot;Cambria Math&quot;,serif">〗</span></span><o:p></o:p></p>
<p>1 . We define a new kind of substitution<o:p></o:p></p>
<p>RULE [7'] Expression substitution :<o:p></o:p></p>
<p>If a word contains an open bracket <b>«<span class="mkuptt">&nbsp;[ »</span></b>&nbsp;immediately followed by an open parenthesis « ( », then Tcl performs an Expression substitution. To do this it invokes the Tcl interpreter recursively to process the characters following
 the open parenthesis as a Tcl mathematical Expression. The Expression must be terminated by a close bracket «&nbsp;<span class="mkuptt"><b>] »&nbsp;</b></span>immediately&nbsp;preceded by a closed parenthesis « ) ». The result of the expression is substituted into the word
 in place of the brackets-parenthesis and all of the characters between them. There may be any number of expression substitutions in a single word. Expression substitution is not performed on words enclosed in braces.<o:p></o:p></p>
<p>2. We create the test in ParseToken<o:p></o:p></p>
<p>... else if (*src == '[') {<o:p></o:p></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;if (src[1] == '(') {<o:p></o:p></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Expression substitution<o:p></o:p></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// must finish by « )] »<o:p></o:p></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; // doesn't know how to do it...&nbsp;<o:p></o:p></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; } else {<o:p></o:p></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;// Command substitution<o:p></o:p></p>
<p>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; }<o:p></o:p></p>
<p>3. we create a -noexpr switch in the subst command<o:p></o:p></p>
<p>....<o:p></o:p></p>
<p>Examples :<o:p></o:p></p>
<p>inline expression :&nbsp;&nbsp;string range "my long sentence" 0 end-[($x+2)]<o:p></o:p></p>
<p>With native list expr enancement :&nbsp;&nbsp;.c create rectangle {*}[( $X , $Y, $X+100, $Y+100 )]<o:p></o:p></p>
<p>With multiples instructions enhancement :&nbsp;&nbsp;set multiexpr [( x = 1; y = 2; $x-$y, $y-$x )]<o:p></o:p></p>
<p>Readable, easy to type, test logically positionned in the C source code, no double substitution, avoiding confusion with variable substitution : This is the solution !<o:p></o:p></p>
<p>Florent<o:p></o:p></p>
<p><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal">Le 22/10/2025 à 15:52, Zaumseil René a écrit&nbsp;:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">And how will this be documented? Imho it should be mentioned in the dodecalogue.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Currently the used syntax is only used as array variable and not as math command.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">I remember the big discussion on {*} syntax here.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Again, is this change really more readable and useable?</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Is the benefit worth the additional syntax.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Why not create real benefit with p.e. a multiple set command ala tip 674.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Or a new math command without need of $.. access to variables.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">&nbsp;</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">Regards</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">rene</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Arial&quot;,sans-serif">&nbsp;</span><o:p></o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span lang="DE" style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif">Von:</span></b><span lang="DE" style="font-size:11.0pt;font-family:&quot;Calibri&quot;,sans-serif"> Florent Merlet
<a href="mailto:flo...@gm...">&lt;flo...@gm...&gt;</a> <br>
<b>Gesendet:</b> Mittwoch, 22. Oktober 2025 15:39<br>
<b>An:</b> <a href="mailto:tc...@ro...">tc...@ro...</a><br>
<b>Cc:</b> <a href="mailto:et...@ro...">et...@ro...</a>; <a href="mailto:tcl...@li...">
tcl...@li...</a><br>
<b>Betreff:</b> [Ext] Re: [TCLCORE] TIP 672 Implementation Complete - Ready for Sponsorship</span><o:p></o:p></p>
</div>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<div>
<p class="MsoNormal">So, everybody in the core team agree with the implementation of a new math-Expression substitution as a memlink command into the procedure in charge of variable name substitution ?&nbsp;<o:p></o:p></p>
</div>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">Le mer. 22 oct. 2025, 14:07, EricT &lt;<a href="mailto:tw...@gm...">tw...@gm...</a>&gt; a écrit&nbsp;:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Hi everyone,<br>
<br>
I wanted to update you on the status of TIP 672 (expression substitution syntax).<br>
<br>
The prototype implementation is now complete and available at:<br>
<a href="https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&amp;d=DwMDaQ&amp;c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&amp;r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&amp;m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&amp;s=ZG5I9vay2CgB9hUAk2I-pkA-6Y6ofRO4-983kuM23Nw&amp;e=" target="_blank">https://github.com/rocketship88/tcl-tip-672-prototype</a><br>
<br>
The implementation has been parameterized to support both discussed approaches with a simple compile-time flag:<br>
- Mode 1: $(expr) syntax<br>
- Mode 2: $=(expr) or $^(expr) - configurable character<br>
<br>
Key features:<br>
- Comprehensive test suite (82 tests covering edge cases)<br>
- Minimal code changes (~100 lines)<br>
- Clean integration with existing parser<br>
- Full Tcl test suite passes (only 3 expected differences)<br>
<br>
There is one known issue: a minor memory leak in the synthetic command strings that will need attention during integration.<br>
<br>
At this point, I need a sponsor to upload the code to a TIP branch on Fossil so the core team can review and decide whether to adopt the TIP and, if so, which syntax to use. I'm available for any collaborative work, questions, or modifications needed.<br>
<br>
I'm grateful for all the feedback and support from the community. I look forward to the next steps in the process.<br>
<br>
Best regards,<o:p></o:p></p>
<div>
<p class="MsoNormal">Eric<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">&nbsp;<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Tcl-Core mailing list<br>
<a href="mailto:Tcl...@li..." target="_blank">Tcl...@li...</a><br>
<a href="https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&amp;d=DwMDaQ&amp;c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&amp;r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&amp;m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&amp;s=4iEQfafWSb-GM4h7dq1Qztghg-qOF6HjeF8W3XUHIzs&amp;e=" target="_blank">https://lists.sourceforge.net/lists/listinfo/tcl-core</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>


<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] TIP 672 Implementation Complete - Ready for Sponsorship

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

(Sorry if this is double posted, I think I sent it off to only Donal
by mistake, really dislike gmail sometimes)

Thanks Donal!

Adding support for $((...)) syntax can be done without too much effort - it
would be a relatively straightforward extension of the existing
parameterization. However, I think that should await TIP approval and would
be a very good exercise for someone else to implement. This would help
ensure the code doesn't depend solely on me going forward.

Given the typical timelines for Tcl changes like these, I may not be
available to help in the future, so having others familiar with the
implementation would be beneficial.

Regarding the aggressive parser testing you mentioned - the current test
suite has 82 edge cases, but I'm sure there are more creative ways to try
to break it. That sounds like fun for the test writers indeed!

I don't have access to the TIP database to update the specification
sections - I've always left that to others who have those permissions. I
see that Jan has already created and uploaded the TIP branch to Fossil
(thank you Jan!). It just needs one more update from the latest code, and
the 82 test cases need to be uploaded if they're not there already.

Thanks for the guidance on the process.

Eric


On Wed, Oct 22, 2025 at 5:23 AM Donal Fellows <
don...@ma...> wrote:

> Just needs the option to do the $((...)) form (double parenthesis) to
> cover the likely bases for what we'll be picking between. I'm guessing
> that once we're closer to having a syntax picked, we'll need some really
> aggressive attempts to break the parser for all of this. Fun for test
> writers... ;-)
>
> There will also need to be a bunch of cleaning up on the formal side
> (e.g., the TIP contains "TBD" for the Specification) before any vote. I
> don't expect a big problem there; just a "can't vote on this yet because
> we're still baking it".
>
> Donal.
>
> ------------------------------
> *From:* EricT <tw...@gm...>
> *Sent:* Wednesday, October 22, 2025 13:06
> *To:* tcl...@li... <Tcl...@li...>
> *Cc:* et...@ro... <et...@ro...>
> *Subject:* [TCLCORE] TIP 672 Implementation Complete - Ready for
> Sponsorship
>
> ZjQcmQRYFpfptBannerEnd
> Hi everyone,
>
> I wanted to update you on the status of TIP 672 (expression substitution
> syntax).
>
> The prototype implementation is now complete and available at:
> https://github.com/rocketship88/tcl-tip-672-prototype [github.com]
> <https://urldefense.com/v3/__https://github.com/rocketship88/tcl-tip-672-prototype__;!!PDiH4ENfjr2_Jw!FnU_lkuFMqro--EqlOuN1ArpdwtqBw99MRZ08bb9K5wa51ZyF6etbvazzvALIqobsO0M1KKypbJcYLKnPozRdEvqhQM$>
>
> The implementation has been parameterized to support both discussed
> approaches with a simple compile-time flag:
> - Mode 1: $(expr) syntax
> - Mode 2: $=(expr) or $^(expr) - configurable character
>
> Key features:
> - Comprehensive test suite (82 tests covering edge cases)
> - Minimal code changes (~100 lines)
> - Clean integration with existing parser
> - Full Tcl test suite passes (only 3 expected differences)
>
> There is one known issue: a minor memory leak in the synthetic command
> strings that will need attention during integration.
>
> At this point, I need a sponsor to upload the code to a TIP branch on
> Fossil so the core team can review and decide whether to adopt the TIP and,
> if so, which syntax to use. I'm available for any collaborative work,
> questions, or modifications needed.
>
> I'm grateful for all the feedback and support from the community. I look
> forward to the next steps in the process.
>
> Best regards,
> Eric
>
> _______________________________________________
> 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

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

That doesn’t seem any better than “set x [= {$y + 1}]”

And the Unicode version gives me flashbacks to early Smalltalk and APL.

I started out in favor of the “$(...)” syntax but this is turning into creeping Perlism.

From: Florent Merlet <flo...@gm...>
Date: Wednesday, October 22, 2025 at 13:20
To: Zaumseil René <RZa...@kk...>, tc...@ro... <tc...@ro...>
Cc: et...@ro... <et...@ro...>, tcl...@li... <Tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Re: TIP 672 Implementation Complete - Ready for Sponsorship
Another alternative proposal : set x [($y+1)] It is very readable, easy to write, there is eventually a unicode version set x 〖$y+1〗 1 . We define a new kind of substitution RULE [7'] Expression substitution : If a word contains an open bracket


Another alternative proposal :

set x [($y+1)]

It is very readable, easy to write, there is eventually a unicode version

set x 〖$y+1〗

1 . We define a new kind of substitution

RULE [7'] Expression substitution :

If a word contains an open bracket « [ » immediately followed by an open parenthesis « ( », then Tcl performs an Expression substitution. To do this it invokes the Tcl interpreter recursively to process the characters following the open parenthesis as a Tcl mathematical Expression. The Expression must be terminated by a close bracket « ] » immediately preceded by a closed parenthesis « ) ». The result of the expression is substituted into the word in place of the brackets-parenthesis and all of the characters between them. There may be any number of expression substitutions in a single word. Expression substitution is not performed on words enclosed in braces.

2. We create the test in ParseToken

... else if (*src == '[') {

           if (src[1] == '(') {

                     // Expression substitution

                     // must finish by « )] »

                    // doesn't know how to do it...

            } else {

                     // Command substitution

            }

3. we create a -noexpr switch in the subst command

....

Examples :

inline expression :  string range "my long sentence" 0 end-[($x+2)]

With native list expr enancement :  .c create rectangle {*}[( $X , $Y, $X+100, $Y+100 )]

With multiples instructions enhancement :  set multiexpr [( x = 1; y = 2; $x-$y, $y-$x )]

Readable, easy to type, test logically positionned in the C source code, no double substitution, avoiding confusion with variable substitution : This is the solution !

Florent


Le 22/10/2025 à 15:52, Zaumseil René a écrit :
And how will this be documented? Imho it should be mentioned in the dodecalogue.
Currently the used syntax is only used as array variable and not as math command.
I remember the big discussion on {*} syntax here.
Again, is this change really more readable and useable?
Is the benefit worth the additional syntax.
Why not create real benefit with p.e. a multiple set command ala tip 674.
Or a new math command without need of $.. access to variables.

Regards
rene

Von: Florent Merlet <flo...@gm...><mailto:flo...@gm...>
Gesendet: Mittwoch, 22. Oktober 2025 15:39
An: tc...@ro...<mailto:tc...@ro...>
Cc: et...@ro...<mailto:et...@ro...>; tcl...@li...<mailto:tcl...@li...>
Betreff: [Ext] Re: [TCLCORE] TIP 672 Implementation Complete - Ready for Sponsorship

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

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

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

The prototype implementation is now complete and available at:
https://github.com/rocketship88/tcl-tip-672-prototype<https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=ZG5I9vay2CgB9hUAk2I-pkA-6Y6ofRO4-983kuM23Nw&e=>

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

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

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

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

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

Best regards,
Eric

_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core<https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=iT87BgHPQz_A0uNwlVbY84Y5W9eaZzr61JhUIsKkQHMwBqGb0HSqTCupNpvqyeMR&s=4iEQfafWSb-GM4h7dq1Qztghg-qOF6HjeF8W3XUHIzs&e=>

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

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

Another alternative proposal :

set x [($y+1)]

It is very readable, easy to write, there is eventually a unicode version

set x 〖$y+1〗

1 . We define a new kind of substitution

RULE [7'] Expression substitution :

If a word contains an open bracket *«** [ »* immediately followed by an 
open parenthesis « ( », then Tcl performs an Expression substitution. To 
do this it invokes the Tcl interpreter recursively to process the 
characters following the open parenthesis as a Tcl mathematical 
Expression. The Expression must be terminated by a close bracket « *] » 
*immediately preceded by a closed parenthesis « ) ». The result of the 
expression is substituted into the word in place of the 
brackets-parenthesis and all of the characters between them. There may 
be any number of expression substitutions in a single word. Expression 
substitution is not performed on words enclosed in braces.

2. We create the test in ParseToken

... else if (*src == '[') {

            if (src[1] == '(') {

                      // Expression substitution

                      // must finish by « )] »

                     // doesn't know how to do it...

             } else {

                      // Command substitution

             }

3. we create a -noexpr switch in the subst command

....

Examples :

inline expression :  string range "my long sentence" 0 end-[($x+2)]

With native list expr enancement :  .c create rectangle {*}[( $X , $Y, 
$X+100, $Y+100 )]

With multiples instructions enhancement :  set multiexpr [( x = 1; y = 
2; $x-$y, $y-$x )]

Readable, easy to type, test logically positionned in the C source code, 
no double substitution, avoiding confusion with variable substitution : 
This is the solution !

Florent


Le 22/10/2025 à 15:52, Zaumseil René a écrit :
>
> And how will this be documented? Imho it should be mentioned in the 
> dodecalogue.
>
> Currently the used syntax is only used as array variable and not as 
> math command.
>
> I remember the big discussion on {*} syntax here.
>
> Again, is this change really more readable and useable?
>
> Is the benefit worth the additional syntax.
>
> Why not create real benefit with p.e. a multiple set command ala tip 674.
>
> Or a new math command without need of $.. access to variables.
>
> Regards
>
> rene
>
> *Von:*Florent Merlet <flo...@gm...>
> *Gesendet:* Mittwoch, 22. Oktober 2025 15:39
> *An:* tc...@ro...
> *Cc:* et...@ro...; tcl...@li...
> *Betreff:* [Ext] Re: [TCLCORE] TIP 672 Implementation Complete - Ready 
> for Sponsorship
>
> So, everybody in the core team agree with the implementation of a new 
> math-Expression substitution as a memlink command into the procedure 
> in charge of variable name substitution ?
>
> Le mer. 22 oct. 2025, 14:07, EricT <tw...@gm...> a écrit :
>
>     Hi everyone,
>
>     I wanted to update you on the status of TIP 672 (expression
>     substitution syntax).
>
>     The prototype implementation is now complete and available at:
>     https://github.com/rocketship88/tcl-tip-672-prototype
>
>     The implementation has been parameterized to support both
>     discussed approaches with a simple compile-time flag:
>     - Mode 1: $(expr) syntax
>     - Mode 2: $=(expr) or $^(expr) - configurable character
>
>     Key features:
>     - Comprehensive test suite (82 tests covering edge cases)
>     - Minimal code changes (~100 lines)
>     - Clean integration with existing parser
>     - Full Tcl test suite passes (only 3 expected differences)
>
>     There is one known issue: a minor memory leak in the synthetic
>     command strings that will need attention during integration.
>
>     At this point, I need a sponsor to upload the code to a TIP branch
>     on Fossil so the core team can review and decide whether to adopt
>     the TIP and, if so, which syntax to use. I'm available for any
>     collaborative work, questions, or modifications needed.
>
>     I'm grateful for all the feedback and support from the community.
>     I look forward to the next steps in the process.
>
>     Best regards,
>
>     Eric
>
>     _______________________________________________
>     Tcl-Core mailing list
>     Tcl...@li...
>     https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

Ok but if you just alias = to expr you're vulnerable to various gotchas 
and unnecessary shimmering of values unless you also brace the 
expression - https://wiki.tcl-lang.org/page/Brace+your+expr%2Dessions.

So you need to write [= {$x-2}] which is an improvement with no 
compatibility issues, and is only one character longer than $(($x-2)).  
It's also the same length as [= $x - 2] which is how that would need to 
be written under my proposal.  I think mine is slightly more readable, 
but the differences are marginal.  Using $($x-2) is certainly neater but 
seems to be disliked on compatibility grounds. So if we come down to a 
choice between [= {expression}] and $((expression)) it's hard to see 
enough benefit to justify a radical new feature.

Colin.

On 22/10/2025 14:49, da Silva, Peter J wrote:
>
> I don’t think it’s reasonable to try and make random language elements 
> immune to upstream metacharacter injection attacks. You have to treat 
> untrusted user input as hostile when you write the code.
>
> I really like the idea of making = an alias for expr, it solves the 
> verbosity issue without introducing new syntax. And if it’s added as a 
> standard language convention it won’t be surprising.
>
> *From: *Colin Macleod via Tcl-Core <tcl...@li...>
> *Date: *Wednesday, October 22, 2025 at 04:43
> *To: *tcl...@li... <tcl...@li...>
> *Subject: *Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - 
> $(expr) Syntax
>
> Hi All, perhaps it's time to boost my own expr proposal again. I like 
> the [= <expr>] idea, but simply aliasing "=" to expr doesn't help much 
> because you still need to brace the expression to avoid 
> double-substitution problems. Unbraced
>
> Hi All, perhaps it's time to boost my own expr proposal again.
>
> I like the [= <expr>] idea, but simply aliasing "=" to expr doesn't 
> help much because you still need to brace the expression to avoid 
> double-substitution problems.  Unbraced works ok for the simple 
> examples Florent gives, but in general is problematic, e.g.
>
> set x {[exec cat /secret/file >/dev/tty]}    ;# x might be set from 
> user input
> ..
> string range "abcdef" 1 end-[= $x-2]      ;# user sees secret file :-(
>
> My own TIP 676 is a proposal to make [= <expression>] usable and 
> safe.  It has the advantage of not requiring any change to the 
> dodekalogue and is fully compatible with existing code.  It also can 
> be used anywhere that [] gets expanded including within quoted 
> strings, which is not the case for the {=}{expr} proposal.
>
> There are some downsides:
> - Operators and operands need to be separated with spaces, i.e.  [= $x 
> - 2]  not  [= $x-2]
> - Only numerical and boolean values can be supported, not string values
> - Lazy evaluation of && || ?: is not supported
> - The implementation is a little more complicated since it can't use 
> the existing [expr] parser.  I supplied a Tcl prototype, linked from 
> the TIP, actual implementation would require translating this into C.
>
> I worked on this in 2023 but put it aside because everyone was 
> focussed on getting 9.0 released, then I moved on to a different 
> project.  I think it's worth considering now that [expr] 
> simplification is back in the spotlight.
>
> Colin.
>
> On 22/10/2025 09:05, Zaumseil René via Tcl-Core wrote:
>
>     +1 on propagating [= …] vs $(..). Using $(..) as command needs
>     additional explanation.
>
>     *Von:*Florent Merlet <flo...@gm...>
>     <mailto:flo...@gm...>
>     *Gesendet:* Mittwoch, 22. Oktober 2025 07:31
>     *An:* Donal Fellows <don...@ma...>
>     <mailto:don...@ma...>;
>     tcl...@li...
>     *Betreff:* Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672
>     - $(expr) Syntax
>
>     Donal,
>
>     Another level is the C source level, whose clarity of code is
>     important too : New generations will learn Tcl in the future.
>
>     On this point of view, does the implementation of the expression
>     shorthand in a procedure whose name is « Tcl_ParseVarname » look
>     so wonderfull ?
>
>     There is already a way to compute a expression in a string, it's
>     through the command substitution []
>
>     with : interp alias {} "=" {} expr
>
>     % string range "abcdef" 1 end-[= 3-2]
>
>     But now, is there really a necessity to pollute the "$"
>     substitution procedure as well, to be able to write :
>
>     % string range "abcdef" 1 end-$(3-2)
>
>     Semantically, « expression substitution » is more like « command
>     substitution » than like « variable substitution ». That's why,
>     Eric, in his change in Tcl_ParseVarname, has to « transmute » the
>     TCL_TOKEN_VARIABLE into a TCL_TOKEN_COMMAND. Now, Tcl_ParseVarname
>     can return either TCL_TOKEN_VAR, TCL_TOKEN_TEXT or TCL_TOKEN_COMMAND.
>
>     The logic is not beautifull. Semantically, the good place for any
>     change like this must be in Tcl_ParseToken, and must rely on the
>     concept of « expression substitution » which has to return
>     a TCL_TOKEN_EXPRESSION
>
>     The question is : on what char(s) make that detection ?
>
>     why not on the equal sign ?
>
>     % string range "abcdef" 1 end-{=}3-2
>
>     Ok, its bracketment is not very readable.
>
>     For this bracketment, it remains unicode chars
>
>     % string range "abcdef" 1 end-⟦3-2⟧
>
>     With its ascii variant :
>
>     % string range "abcdef" 1 end-[|3-2|]
>
>     Florent
>
>     Le 21/10/2025 à 23:18, Donal Fellows a écrit :
>
>         We /can/ match all sorts of things. What matters is what we
>         /should/ match. What is in play is how much of a syntactic
>         incompatibility we are willing to stomach. If we decide that
>         we are rejecting /any/ syntax changes that could possibly have
>         a compatibility impact, we have /only/ the option to /reject/
>         /all/ change.
>
>         The key thing that we are looking for here is to be a
>         syntactic alternative for *[expr {expression...}]*, which has
>         many potential uses. The option with {=} has the disadvantage
>         of not being naturally bracketed unless written as
>         *{=}{expression...}* and that's just not the nicest thing (for
>         {*}, we were dealing with reinterpretation of words, with the
>         freedom and restrictions that implies, but that's not in play
>         here), and gets ugly when used in the interior of a word. The
>         options with *$(expression...)* and *$((expression...))* are
>         /much/ less of a problem in that regard... but have more
>         potential for compatibility problems. (These are
>         non-theoretical issues for the *$(expression...)* form, which
>         is /definitely/ in use in the wild; we have found many
>         examples, even if we've not yet worked out if they're truly a
>         problem in all cases.)
>
>         Exactly which code should be adapted once we decide what the
>         language change should be... is just a simple matter of
>         changing what needs changing. In terms of commands affected, I
>         can predict this will have an impact inside *subst* primarily,
>         and possibly *assemble*; I see no need to add it to the
>         expression language.
>
>         Note of course that expressions are expected to syntactically
>         have balanced parentheses (except for comments).
>
>         Donal.
>
>         -------- Original message --------
>
>         From: Florent Merlet <flo...@gm...>
>         <mailto:flo...@gm...>
>
>         Date: 21/10/2025 20:01 (GMT+00:00)
>
>         To: tc...@ro...
>
>         Cc: tcl...@li...
>
>         Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP
>         672 - $(expr) Syntax
>
>         Why not ? {=} can be check in Tcl_ParseToken.
>
>     -- 
>
>     ------------------------------------------------------------------------
>
>     *Florent MERLET*
>     /4 rue Johann Strauss
>     Logement 7
>     86180 BUXEROLLES/
>
>     ------------------------------------------------------------------------
>
>     *Mél.* : /flo...@gm.../
>     *Tél.* : /06 70 00 63 48/
>
>
>
>
>     _______________________________________________
>
>     Tcl-Core mailing list
>
>     Tcl...@li...
>
>     https://lists.sourceforge.net/lists/listinfo/tcl-core  <https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=qlVAdTeNR2-pXS3j_2QUxkwF-zAnAKn280uiCTQxlrKGO8FXb5HwJAg-GzNklZ3F&s=vLrLLZ6yEAxV7iIdm5yDVWuwhmj4EgIJ7-td44Tk_o0&e=>
>

[TCLCORE] tklib detritus

[Brian G. <bri...@ea...>]

I noticed yesterday that there are several random files in the tklib-0.9 archives on SourceForge, that are not present in the fossil repository. 
Specifically:

% diff --brief -r tklib tklib-0.9
Only in tklib-0.9: CHECK.arjen
Only in tklib-0.9: CHECK.csaba
Only in tklib-0.9: check-files.sh
Only in tklib-0.9: check-list
Only in tklib-0.9: check.sh
Only in tklib-0.9: doc
Only in tklib-0.9: LOCATIONS.txt
Only in tklib-0.9: M
Only in tklib-0.9/modules/canvas: canvas_epoints.tcl.work
Only in tklib-0.9/modules/canvas: canvas_epolyline.tcl.work

These differences I would expect:

Only in tklib: .fossil-settings
Only in tklib: .fslckout
Files tklib/support/releases/PACKAGES and tklib-0.9/support/releases/PACKAGES differ
Only in tklib-0.9/support/releases: PACKAGES.LAST
Files tklib/tklib.tap and tklib-0.9/tklib.tap differ
	

Maybe someone can update these archives lest they some how circle back around into the repository.

Thanks!
-Brian

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

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

> On Oct 22, 2025, at 9:39 AM, Florent Merlet <flo...@gm...> wrote:
> 
> So, everybody in the core team agree with the implementation of a new math-Expression substitution as a memlink command into the procedure in charge of variable name substitution ? 

I need to make sure I understand what the stakes of this TIP are. In exchange for some syntactic sugar on [expr], we have to accept some breaking changes on variable substitution?

—Kevin

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

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

Hi Brian,

thanks a lot for the clarification regarding the new defaults in TclTLS 2.0.

It’s great to hear that the -servername is now automatically derived from the host used in tls::socket, and that this behavior aligns with modern SNI expectations. That does indeed sound like it resolves the original issue I had when contacting multiple HTTPS hosts.

Also, the note regarding tls::import and the need to explicitly pass -servername makes sense, since the original socket doesn’t retain the hostname context.

I appreciate the effort that went into improving the defaults — especially removing the need to manually set TLS protocol versions. These changes make the usage much more intuitive and modern.

I’ll experiment with the new v2.0 behavior in practice, but based on your explanation, this seems to cover my use case quite well.

Thanks again!
Alex

> Am 22.10.2025 um 15:59 schrieb Brian O’Hagan <bri...@co...>:
> 
> In TclTLS 2.0 you don’t need to (but can) use the -autoservername anymore. If you provide the right host to the tls::socket command, it will automatically be used for the -servername argument. That is what is used for SNI. You can override this by specifying -servername if you need to use a different name for SNI. As long as you don’t use -servername for the tls::init command, each connection will use its own host for SNI. So, I think the default does what you want now.
> 
> Please note if you use socket then tls::import, you must use the -servername option. Since the socket command does not preserve the host you used, the tls::import command has no other way to get it.
> 
> The the big change is you don’t need to specify which TLS protocol versions to use. It will default to only allowing TLS 1.2 and 1.3, which is what most servers will only allow nowadays. My main goal in the option default changes was so you don't need to figure it out. It will just work.
> 
> 
>> On Oct 22, 2025, at 3:39 AM, Alexander Schöpe <a.s...@gm...> wrote:
>> 
>> Hi Harald
>> thank you for the info. I’m aware of the -autoservername option introduced in TclTLS 1.7.1, but I suspect it may not fully solve the issue in my case, especially when using multiple HTTPS hosts within the same script.
>> 
>> From what I can tell, TclTLS 2 introduces some changes to how these options behave, and the handling seems to differ compared to 1.x versions. I’ve been reviewing the updated documentation here:
>>  • https://chiselapp.com/user/bohagan/repository/TCLTLS/file?name=doc/tls.html&ci=tip
>>  • https://chiselapp.com/user/bohagan/repository/TCLTLS/wiki?name=TCLTLS+Redux
>> 
>> It appears that -servername now defaults to the socket host, and -autoservername defaults to true if not explicitly set – which should help in most cases. However, I’m still unsure how to handle dynamic connections to different servers if the TLS context needs to be unique per request.
>> 
>> I saw that Brian posted a detailed message about TclTLS 2 on the newsgroup. That might cover exactly what I’m running into.
>> If possible, I’d appreciate it if you could forward his message to the Tcl core mailing list – or perhaps Brian could directly comment on this?
>> 
>> Best,
>> Alex
>> 
>>> Am 22.10.2025 um 08:33 schrieb Harald Oehlmann <har...@el...>:
>>> Alex,
>>> TCLTLS 1.7.1 introduced "-autoservername" option.
>>> Does this solve your issue?
>>> Harald
>>>> Am 22.10.2025 um 08:26 schrieb Alexander Schöpe via Tcl-Core:
>>>> Hi Brian,
>>>> I have a question regarding the use of tcltls in combination with the http package, specifically concerning Server Name Indication (SNI).
>>>> Recently, it seems that some Apache web servers have changed their configuration, and I’m increasingly encountering the 421 Misdirected Request error when making HTTPS requests without explicitly setting the servername field during the TLS handshake.
>>>> The error message is typically something like:
>>>> The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.
>>>> I’ve been able to work around this issue for a single target server by explicitly registering HTTPS like this:
>>>> http::register https 443 [list ::tls::socket -tls1 1 -servername bla.example.com]
>>>> However, my question is:
>>>> What is the recommended approach if I need to contact multiple different HTTPS servers within the same Tcl script?
>>>> Since http::register is global for the https scheme, it doesn’t seem possible to dynamically assign the -servername per connection.
>>>> Is there a best practice or suggested workaround – perhaps by creating a custom socket for each http::geturl call with the correct SNI set depending on the target host?
>>>> Any advice would be much appreciated.
>>>> Best
>>>> Alex
>>> _______________________________________________
>>> Tcl-Core mailing list
>>> Tcl...@li...
>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 

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

[Rolf A. <tcl...@po...>]

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

It isn't necessary at all that everybody in the core team agrees with a
proposal to have the implementation in a branch of the repository. It is
just one step which helps to play around what is proposed and how it is
implemented and to eventually have an informed option.

Having a branch with an implementation isn't a preliminary decision at
all.

Speaking for me I'm still in the listening and considering phase. No
surprise that there seems consent that the [expr ...] syntax is somewhat
awkward. Everything proposed to far has a (more or less minor) drawback.
Perhaps there is no solution without drawback and we will have to pick
one. Or none will be picked and things stay as it is until the next
round of this disussion start ...

rolf

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

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

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

Am 22.10.2025 um 15:38 schrieb Florent Merlet:
> So, everybody in the core team agree with the implementation of a new 
> math-Expression substitution as a memlink command into the procedure in 
> charge of variable name substitution ?
This will not work, sorry.
Core-team members are just like you and me. With the difference, that 
they are forced to look to TIPs on vote.
But they mostly don't vote, as the subject and burden is to high.
A real opinion will be found when voted.
They tend to be silent, as there is often the expectation that "the core 
team" does something. No, it doesn't, sorry.

A key member, Ashok, has currently Dwali holidays.
Sorry, it will take time.

We will find a solution.

Take care,
Harald

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

[Brian O’H. <bri...@co...>]

In TclTLS 2.0 you don’t need to (but can) use the -autoservername anymore. If you provide the right host to the tls::socket command, it will automatically be used for the -servername argument. That is what is used for SNI. You can override this by specifying -servername if you need to use a different name for SNI. As long as you don’t use -servername for the tls::init command, each connection will use its own host for SNI. So, I think the default does what you want now.

Please note if you use socket then tls::import, you must use the -servername option. Since the socket command does not preserve the host you used, the tls::import command has no other way to get it.

The the big change is you don’t need to specify which TLS protocol versions to use. It will default to only allowing TLS 1.2 and 1.3, which is what most servers will only allow nowadays. My main goal in the option default changes was so you don't need to figure it out. It will just work.


> On Oct 22, 2025, at 3:39 AM, Alexander Schöpe <a.s...@gm...> wrote:
> 
> Hi Harald
> thank you for the info. I’m aware of the -autoservername option introduced in TclTLS 1.7.1, but I suspect it may not fully solve the issue in my case, especially when using multiple HTTPS hosts within the same script.
> 
> From what I can tell, TclTLS 2 introduces some changes to how these options behave, and the handling seems to differ compared to 1.x versions. I’ve been reviewing the updated documentation here:
>   • https://chiselapp.com/user/bohagan/repository/TCLTLS/file?name=doc/tls.html&ci=tip
>   • https://chiselapp.com/user/bohagan/repository/TCLTLS/wiki?name=TCLTLS+Redux
> 
> It appears that -servername now defaults to the socket host, and -autoservername defaults to true if not explicitly set – which should help in most cases. However, I’m still unsure how to handle dynamic connections to different servers if the TLS context needs to be unique per request.
> 
> I saw that Brian posted a detailed message about TclTLS 2 on the newsgroup. That might cover exactly what I’m running into.
> If possible, I’d appreciate it if you could forward his message to the Tcl core mailing list – or perhaps Brian could directly comment on this?
> 
> Best,
> Alex
> 
>> Am 22.10.2025 um 08:33 schrieb Harald Oehlmann <har...@el...>:
>> Alex,
>> TCLTLS 1.7.1 introduced "-autoservername" option.
>> Does this solve your issue?
>> Harald
>>> Am 22.10.2025 um 08:26 schrieb Alexander Schöpe via Tcl-Core:
>>> Hi Brian,
>>> I have a question regarding the use of tcltls in combination with the http package, specifically concerning Server Name Indication (SNI).
>>> Recently, it seems that some Apache web servers have changed their configuration, and I’m increasingly encountering the 421 Misdirected Request error when making HTTPS requests without explicitly setting the servername field during the TLS handshake.
>>> The error message is typically something like:
>>> The client needs a new connection for this request as the requested host name does not match the Server Name Indication (SNI) in use for this connection.
>>> I’ve been able to work around this issue for a single target server by explicitly registering HTTPS like this:
>>> http::register https 443 [list ::tls::socket -tls1 1 -servername bla.example.com]
>>> However, my question is:
>>> What is the recommended approach if I need to contact multiple different HTTPS servers within the same Tcl script?
>>> Since http::register is global for the https scheme, it doesn’t seem possible to dynamically assign the -servername per connection.
>>> Is there a best practice or suggested workaround – perhaps by creating a custom socket for each http::geturl call with the correct SNI set depending on the target host?
>>> Any advice would be much appreciated.
>>> Best
>>> Alex
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core