tcl-core — Tcl Core Team discussions about Tcl development

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

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

When you created your array, the index was (2+2) which is 5 chars in
length, and you set the value to 5. When you wanted to retrieve it as an
array(index) and array was actually the null variable, you needed to do
((2+2)) in order to enclose your index in parentheses. You could probably
see it more clearly as,

% set foo((2+2)) 5
5
% array name foo
(2+2)
% puts $foo((2+2))
can't read "foo((2+2)": no such element in array
% set foo((2+2))
5

However, that is 8.6, and the problem appears to be that they stopped at
the first close paren, without doing any balancing. With 9.1 I see the new
error, same as you are getting, although to try it out I had to use a real
array name. Looking at the code, there's a change in 9.x which includes
this and explains the different error messages:

} else if ((*parsePtr->term != ')')){
 if (parsePtr->interp != NULL) {
   Tcl_SetObjResult(parsePtr->interp, Tcl_NewStringObj(
   "invalid character in array index", -1));
 }


The else if is checking the terminating character for the parse. Stepping
it through however, I see that it actually is pointing to the 2nd open
paren following the array name. So, it has scanned the name, saw the first
(, changed to the array logic, but seems to not be pointing at the final
close ) as I would have expected it to and what this code seems to think it
should be as well. This may be a bug. It could explain why they added this
change, but it fails when the first character in the index is an open
paren. You might want to file a ticket on this.

Eric


On Mon, Oct 20, 2025 at 5:34 PM Phillip Brooks <phi...@um...> wrote:

> Thanks for the explanation.   Yes, I did try to run both commands
> together.  I see what is going on with that statement now.  I was unaware
> of the possibility of having an unnamed array previously.
>
> Regarding my Tcl version, I am running vanilla 9.1 of a fairly recent
> vintage, but also tried using 8.5.
>
> Regarding the double parenthesis expression proposal, I'm not sure that I
> follow you.  Is there a way to use the single argument set command to
> create an ambiguity between $(( expression )) as an arithmetic expression
> evaluator and some existing code using an unnamed array, or set (or any
> other currently legal syntax)?  Since that command doesn't involve the $
> character, I don't see how it gets in the way.  If you can think of one,
> can you write a couple of lines of code that illustrate it?
>
> Phil
>
>
>
> On Mon, Oct 20, 2025 at 5:07 PM EricT <tw...@gm...> wrote:
>
>> I believe the reason you got the error was that you actually typed both
>> statements, setting the scalar null variable and then tried the array null
>> variable.
>>
>> However, I believe the problem is that you are running into some parser
>> issues here that the manual doesn't mention. It does, however, say
>>
>> Note that variables may contain character sequences other than those
>> listed above, but in that case other mechanisms must be used to access them
>> (e.g., via the *set *command's single-argument form).
>>
>> And so that is why the above using set does return the value 5. But when
>> trying $ substitution, the rules are more restrictive, and you likely hit
>> one of the edge cases here.
>>
>> Eric
>>
>>
>> On Mon, Oct 20, 2025 at 4:30 PM Phillip Brooks <phi...@um...>
>> wrote:
>>
>>> Let me try making my previous email a little more concise since it
>>> hasn't generated any follow-ups.
>>>
>>> 1) Is there a bust in the TIP 672 example code.  I can't run this code
>>> from the TIP:
>>>
>>> set {} foobar             ;# scalar variable
>>>
>>> set (index) "array value" ;# array variable
>>>
>>> When I run that, I get:
>>>
>>> can't set "(index)": variable isn't array
>>>
>>>
>>> Please explain.
>>>
>>> 2) The bash shell uses the syntax $(( expression )) for arithmetic.
>>> Does that syntax solve the problem of the unnamed array ambiguity that $(
>>> expression ) introduces?  The $(( expression )) syntax, at least in my
>>> small example, seems illegal.  I am only testing this out on a simple case
>>> I tried after the above code didn't work:
>>>
>>> % array set {} { 2+2 5 }
>>>
>>> % puts $(2+2)
>>>
>>> 5
>>>
>>>
>>> The above code illustrates the problem with $(2+2) being interpreted as
>>> an index into the unnamed array.  If I try doing that with an extra ( in
>>> the expression, it is invalid syntax:
>>>
>>> % array set {} { (2+2) 5 }
>>>
>>> % puts $((2+2))
>>>
>>> invalid character in array index
>>>
>>>
>>> To get at the array element named (2+2), you have to add escape
>>> characters:
>>>
>>>
>>> % puts $(\(2+2\))
>>>
>>> 5
>>>
>>>
>>> It seems to me that if $(( expression )) works generally, it has several
>>> advantages:
>>>
>>>    - it is easier to read and type than {=}{ expression }.  (While {=}
>>>    adds only two characters, { and } are shifted, = is unshifted which makes
>>>    for much slower typing.)
>>>    - it has precedent in bash
>>>    - it doesn't overload the meaning of preexisting valid syntax.
>>>
>>> Are there other issues with $(( expression )) that I don't know of?
>>> Please explain?
>>>
>>> Phil
>>> _______________________________________________
>>> 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] Prototype Implementation of TIP 672 - $(expr) Syntax

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

Thanks for the explanation.   Yes, I did try to run both commands
together.  I see what is going on with that statement now.  I was unaware
of the possibility of having an unnamed array previously.

Regarding my Tcl version, I am running vanilla 9.1 of a fairly recent
vintage, but also tried using 8.5.

Regarding the double parenthesis expression proposal, I'm not sure that I
follow you.  Is there a way to use the single argument set command to
create an ambiguity between $(( expression )) as an arithmetic expression
evaluator and some existing code using an unnamed array, or set (or any
other currently legal syntax)?  Since that command doesn't involve the $
character, I don't see how it gets in the way.  If you can think of one,
can you write a couple of lines of code that illustrate it?

Phil



On Mon, Oct 20, 2025 at 5:07 PM EricT <tw...@gm...> wrote:

> I believe the reason you got the error was that you actually typed both
> statements, setting the scalar null variable and then tried the array null
> variable.
>
> However, I believe the problem is that you are running into some parser
> issues here that the manual doesn't mention. It does, however, say
>
> Note that variables may contain character sequences other than those
> listed above, but in that case other mechanisms must be used to access them
> (e.g., via the *set *command's single-argument form).
>
> And so that is why the above using set does return the value 5. But when
> trying $ substitution, the rules are more restrictive, and you likely hit
> one of the edge cases here.
>
> Eric
>
>
> On Mon, Oct 20, 2025 at 4:30 PM Phillip Brooks <phi...@um...> wrote:
>
>> Let me try making my previous email a little more concise since it hasn't
>> generated any follow-ups.
>>
>> 1) Is there a bust in the TIP 672 example code.  I can't run this code
>> from the TIP:
>>
>> set {} foobar             ;# scalar variable
>>
>> set (index) "array value" ;# array variable
>>
>> When I run that, I get:
>>
>> can't set "(index)": variable isn't array
>>
>>
>> Please explain.
>>
>> 2) The bash shell uses the syntax $(( expression )) for arithmetic.  Does
>> that syntax solve the problem of the unnamed array ambiguity that $(
>> expression ) introduces?  The $(( expression )) syntax, at least in my
>> small example, seems illegal.  I am only testing this out on a simple case
>> I tried after the above code didn't work:
>>
>> % array set {} { 2+2 5 }
>>
>> % puts $(2+2)
>>
>> 5
>>
>>
>> The above code illustrates the problem with $(2+2) being interpreted as
>> an index into the unnamed array.  If I try doing that with an extra ( in
>> the expression, it is invalid syntax:
>>
>> % array set {} { (2+2) 5 }
>>
>> % puts $((2+2))
>>
>> invalid character in array index
>>
>>
>> To get at the array element named (2+2), you have to add escape
>> characters:
>>
>>
>> % puts $(\(2+2\))
>>
>> 5
>>
>>
>> It seems to me that if $(( expression )) works generally, it has several
>> advantages:
>>
>>    - it is easier to read and type than {=}{ expression }.  (While {=}
>>    adds only two characters, { and } are shifted, = is unshifted which makes
>>    for much slower typing.)
>>    - it has precedent in bash
>>    - it doesn't overload the meaning of preexisting valid syntax.
>>
>> Are there other issues with $(( expression )) that I don't know of?
>> Please explain?
>>
>> Phil
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>

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

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

I believe the reason you got the error was that you actually typed both
statements, setting the scalar null variable and then tried the array null
variable.

I should have made that clear that those two statements weren't to be
executed together. I was illustrating that there were actually 2 null
variables, one for a scalar and one for an array. They are, however,
mutually exclusive.

Once you created the scalar null variable, you have to unset it to use the
array null variable. That's another reason I would stay away from using
null variables, had you done this,

% set foo something
something
% set foo(index) something-else
can't set "foo(index)": variable isn't array

I think then you would have realized the problem instantly.

Also, are you running with the $(expr) enabled code or 8.6 or 9.x? I am
unable to reproduce your exact error. Here's what I get with 8.6

% array set {} { (2+2) 5 }
%  puts $((2+2))
can't read "((2+2)": no such element in array
% set ((2+2))
5

However, I believe the problem is that you are running into some parser
issues here that the manual doesn't mention. It does, however, say

Note that variables may contain character sequences other than those listed
above, but in that case other mechanisms must be used to access them (e.g.,
via the *set *command's single-argument form).

And so that is why the above using set does return the value 5. But when
trying $ substitution, the rules are more restrictive, and you likely hit
one of the edge cases here.

Eric


On Mon, Oct 20, 2025 at 4:30 PM Phillip Brooks <phi...@um...> wrote:

> Let me try making my previous email a little more concise since it hasn't
> generated any follow-ups.
>
> 1) Is there a bust in the TIP 672 example code.  I can't run this code
> from the TIP:
>
> set {} foobar             ;# scalar variable
>
> set (index) "array value" ;# array variable
>
> When I run that, I get:
>
> can't set "(index)": variable isn't array
>
>
> Please explain.
>
> 2) The bash shell uses the syntax $(( expression )) for arithmetic.  Does
> that syntax solve the problem of the unnamed array ambiguity that $(
> expression ) introduces?  The $(( expression )) syntax, at least in my
> small example, seems illegal.  I am only testing this out on a simple case
> I tried after the above code didn't work:
>
> % array set {} { 2+2 5 }
>
> % puts $(2+2)
>
> 5
>
>
> The above code illustrates the problem with $(2+2) being interpreted as an
> index into the unnamed array.  If I try doing that with an extra ( in the
> expression, it is invalid syntax:
>
> % array set {} { (2+2) 5 }
>
> % puts $((2+2))
>
> invalid character in array index
>
>
> To get at the array element named (2+2), you have to add escape characters:
>
>
> % puts $(\(2+2\))
>
> 5
>
>
> It seems to me that if $(( expression )) works generally, it has several
> advantages:
>
>    - it is easier to read and type than {=}{ expression }.  (While {=}
>    adds only two characters, { and } are shifted, = is unshifted which makes
>    for much slower typing.)
>    - it has precedent in bash
>    - it doesn't overload the meaning of preexisting valid syntax.
>
> Are there other issues with $(( expression )) that I don't know of?
> Please explain?
>
> Phil
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

Let me try making my previous email a little more concise since it hasn't
generated any follow-ups.

1) Is there a bust in the TIP 672 example code.  I can't run this code from
the TIP:

set {} foobar             ;# scalar variable

set (index) "array value" ;# array variable

When I run that, I get:

can't set "(index)": variable isn't array


Please explain.

2) The bash shell uses the syntax $(( expression )) for arithmetic.  Does
that syntax solve the problem of the unnamed array ambiguity that $(
expression ) introduces?  The $(( expression )) syntax, at least in my
small example, seems illegal.  I am only testing this out on a simple case
I tried after the above code didn't work:

% array set {} { 2+2 5 }

% puts $(2+2)

5


The above code illustrates the problem with $(2+2) being interpreted as an
index into the unnamed array.  If I try doing that with an extra ( in the
expression, it is invalid syntax:

% array set {} { (2+2) 5 }

% puts $((2+2))

invalid character in array index


To get at the array element named (2+2), you have to add escape characters:


% puts $(\(2+2\))

5


It seems to me that if $(( expression )) works generally, it has several
advantages:

   - it is easier to read and type than {=}{ expression }.  (While {=} adds
   only two characters, { and } are shifted, = is unshifted which makes for
   much slower typing.)
   - it has precedent in bash
   - it doesn't overload the meaning of preexisting valid syntax.

Are there other issues with $(( expression )) that I don't know of?  Please
explain?

Phil

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

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

Thanks to Jan for proactively making changes, I see he realized that
it needed to be [set (...)] in his case. Looking at the diff, it's not
as difficult to use [set] as I first thought.

Kenny:

Good point - automatic detection is indeed tricky when variable
substitution is involved in $($var). The pragma idea set to error mode
requires human review of each case, which isn't ideal but ensures
developers make conscious decisions about their code.

You're right that {=}{expression} avoids this particular
incompatibility. I think {=} could potentially work, though my sense
is it would require more extensive parser changes to handle quotes and
bare words (where $ already works naturally). But I could be wrong
about the implementation complexity.

Both approaches have their merits - I've just found $(expr) more
straightforward to implement by leveraging existing $ substitution.
But I appreciate the {=} proposal and the comparison is helpful.

Eric


On Mon, Oct 20, 2025 at 3:57 PM Kevin Kenny <kev...@gm...> wrote:

> On Mon, Oct 20, 2025 at 6:47 PM EricT <tw...@gm...> wrote:
>
>> One thing I just discovered which will make migration slightly more
>> difficult is that my suggestion of using ${(index)} will only work on a
>> constant string of index. In order to update $($var)  where $var also
>> includes any [command] substitution, it must be changed to use [set ($var)]
>> since the {}'s in the ${name} also suppress substitution.
>>
>
> I was just going to warn that substitution is indeed performed between the
> () on $arrayName() (including with a vacuous arrayName), making automatic
> detection of the incompatibility difficult in that case.
>
> {=}{expression} is, of course, free of any such trouble, since it's
> entirely new syntax.
>
>
> --
> 73 de ke9tv/2, Kevin
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

[Kevin K. <kev...@gm...>]

On Mon, Oct 20, 2025 at 6:47 PM EricT <tw...@gm...> wrote:

> One thing I just discovered which will make migration slightly more
> difficult is that my suggestion of using ${(index)} will only work on a
> constant string of index. In order to update $($var)  where $var also
> includes any [command] substitution, it must be changed to use [set ($var)]
> since the {}'s in the ${name} also suppress substitution.
>

I was just going to warn that substitution is indeed performed between the
() on $arrayName() (including with a vacuous arrayName), making automatic
detection of the incompatibility difficult in that case.

{=}{expression} is, of course, free of any such trouble, since it's
entirely new syntax.


-- 
73 de ke9tv/2, Kevin

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

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

Christian: Thanks for that info. This means a phased rollout is definitely
needed. However, the fixes can be done ahead of time and remain valid even
if tip 672 is never approved. But see below:

Jan: Thanks so much for testing. I'm curious, when you say tip-672, did you
get it from my repository or has someone added this to the fossil as a
branch? If so, I hope it is the very latest, since I'd updated my
repository at github just the other day.

One thing I just discovered which will make migration slightly more
difficult is that my suggestion of using ${(index)} will only work on a
constant string of index. In order to update $($var)  where $var also
includes any [command] substitution, it must be changed to use [set ($var)]
since the {}'s in the ${name} also suppress substitution.

Tcl can certainly produce surprises!

Eric


On Mon, Oct 20, 2025 at 3:33 PM Jan Nijtmans <jan...@gm...> wrote:

>
>
> Op ma 20 okt 2025 om 22:46 schreef Arjen Markus via Tcl-Core <
> tcl...@li...>:
>
>> Hi Eric, everyone,
>>
>>
>>
>> Just for your information: The one extension that I know of that uses an
>> anonymous array is stooop – Simple Tcl-only object-oriented programming –
>> by Jean-Luc Fontaine. It is part of Tcllib.
>>
>
>
> In order to see how bad it is, I did an experiment, how much work
> it is to fix stooop working with TIP #672
>
> Here is the result, it works!     ;-)
>     <https://core.tcl-lang.org/tcllib/timeline?r=tip-672>
> I ran the tcllib testsuite with Tcl's tip-672 branch.
> Stooop was the only tcllib module which needed
> modification.
>
> Howdee
>      Jan Nijtmans
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

[Kevin K. <kev...@gm...>]

I thought that stooop client code also used $(...) to access instance
variables?

73 de ke9tv/2, Kevin

On Mon, Oct 20, 2025, 18:33 Jan Nijtmans <jan...@gm...> wrote:

>
>
> Op ma 20 okt 2025 om 22:46 schreef Arjen Markus via Tcl-Core <
> tcl...@li...>:
>
>> Hi Eric, everyone,
>>
>>
>>
>> Just for your information: The one extension that I know of that uses an
>> anonymous array is stooop – Simple Tcl-only object-oriented programming –
>> by Jean-Luc Fontaine. It is part of Tcllib.
>>
>
>
> In order to see how bad it is, I did an experiment, how much work
> it is to fix stooop working with TIP #672
>
> Here is the result, it works!     ;-)
>     <https://core.tcl-lang.org/tcllib/timeline?r=tip-672>
> I ran the tcllib testsuite with Tcl's tip-672 branch.
> Stooop was the only tcllib module which needed
> modification.
>
> Howdee
>      Jan Nijtmans
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

Op ma 20 okt 2025 om 22:46 schreef Arjen Markus via Tcl-Core <
tcl...@li...>:

> Hi Eric, everyone,
>
>
>
> Just for your information: The one extension that I know of that uses an
> anonymous array is stooop – Simple Tcl-only object-oriented programming –
> by Jean-Luc Fontaine. It is part of Tcllib.
>


In order to see how bad it is, I did an experiment, how much work
it is to fix stooop working with TIP #672

Here is the result, it works!     ;-)
    <https://core.tcl-lang.org/tcllib/timeline?r=tip-672>
I ran the tcllib testsuite with Tcl's tip-672 branch.
Stooop was the only tcllib module which needed
modification.

Howdee
     Jan Nijtmans

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

[Christian W. <Chr...@t-...>]

On 10/20/2025 09:11 PM, Arjen Markus via Tcl-Core wrote:

> ...
> Just for your information: The one extension that I know of that uses an anonymous array is stooop – Simple Tcl-only object-oriented programming – by Jean-Luc Fontaine. It is part of Tcllib.

There are some more candidates:

   tcllib     - struct/sets_tcl.tcl
   tcllib     - ident/ident.tcl
   tklib      - tkpiechart
   notebook   - helpbrowser
   ulis       - Hugelist etc.
   twapi/iocp - in some test scripts
   gridplus
   nsf
   vqtcl

These were quickly identified (but not further inspected and verified) using

   find . -name '*.tcl' | xargs fgrep 'set ('

and

   find . -name '*.tcl' | xargs fgrep '$('

on an AndroWish source tree which has a bunch of extensions. OK, that is 8.6
based but we get at least an idea.

Hope this info helps somehow,
Christian

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

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

Thanks Arjen for the heads-up! This is exactly why I think a phased
rollout with the pragma approach is the best path forward - it gives
time to identify and update all such uses to the ${(index)} syntax
before enabling the feature.

Colin:

The "macro" approach is something I think could have other uses as
well. In the case of $(expr) it's strength is in the security aspect,
which generates fully braced expr.

By having an easier way to write expressions, users would likely
gravitate to it over time thus improving overall Tcl security. Using
{=}{...} instead of [expr {...}] doesn't seem as compelling for those
seeking cleaner syntax who would also get better security as a
by-product.

I hesitate to mention this here, but I've found a new injection
exploit in 9.x that needs to be fixed. The fix would be much less
traumatic if $(expr) were implemented in 9.x, thus I feel that waiting
for version 10, which could be many years away, is a mistake. I think
a pragma (or knob) approach would be a better plan.

I also see the {=}{expr} approach as a much more difficult
implementation challenge.

Firstly, {*} has to begin a word, it cannot be used inside of a
bareword or a quoted word. That makes it much easier to deal with. For
example, you can't have {*}{1 2 3}xyz or you get an error of extra
characters after close-brace. But you can have - set foo $(1+2)xyz -
and end up with 3xyz.

The parser has separate mechanisms for scanning quoted strings and
bareword strings. The $ trigger works in both of those cases, and need
not begin at a word boundary. I think that trying to wedge {=} into
the parser could likely result in many more edge cases. Certainly, it
would take more than the 100 lines of code that $(expr) required.

And I suspect somewhere in the wild there's a quoted string that has
that pattern in it, perhaps {=}{=}{=} which would be enough to trigger
the substitution. Users all know that if they use a $ in a quoted
string, that it's special.

There is one other edge case with $(expr): the subst command currently
treats it as variable substitution. This means:
subst -nocommands {$(expr)}    # Doesn't work - still substitutessubst
-novariables {$(expr)}   # Works - suppresses substitution

This is addressable but needs consideration.

However, I have not fully investigated how {=}{expr} would interact
with subst, so it may have similar challenges.

--Eric


On Mon, Oct 20, 2025 at 1:46 PM Arjen Markus via Tcl-Core <
tcl...@li...> wrote:

> Hi Eric, everyone,
>
>
>
> Just for your information: The one extension that I know of that uses an
> anonymous array is stooop – Simple Tcl-only object-oriented programming –
> by Jean-Luc Fontaine. It is part of Tcllib.
>
>
>
> Regards,
>
>
>
> Arjen
>
>
>
> *From:* EricT <tw...@gm...>
> *Sent:* maandag 20 oktober 2025 19:45
> *To:* Colin Macleod <col...@ya...>
> *Cc:* tcl...@li...
> *Subject:* Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr)
> Syntax
>
>
>
> *Caution:* This message was sent from outside of Deltares. Please do not
> click links or open attachments unless you recognize the source of this
> email and know the content is safe. Please report all suspicious emails to "
> Ser...@de..." as an attachment.
>
>
>
> Besides for the jimtcl compatibility and its track record in use, there's
> another reason I like the $(expr) notation and that is that it acts in all
> ways like $var, so that what people have learned, such as how to use $
> substitution in event callbacks, either by [list puts $var] or {puts $var}
> depending on whether or not they want delayed evaluation, would be similar
> for [list puts $(expr)] and {puts $(expr)}.
>
>
>
> One other issue that came up in my testing was that my first upload to
> github a few days ago required that ()'s be balanced in the entire
> expression, including when there were command callbacks, such as
>
>
>
> [string length abc(def]+$n
>
>
>
> That would have needed to be escaped as abc\(def, but that restriction has
> been eliminated in the most recent code in my repository. It turns out that
> ()'s need to be balanced ONLY in the portions of an expression that are
> arithmetical, where, for example,  (((1+2))) balancing would be required.
> The fix is in the latest upload to the repository. This makes it compatible
> with expr which also does not require balancing of ()'s in command callback
> strings whether bare or quoted.
>
>
>
> One other fix was to eliminate the code that was changing newlines to
> spaces when found in an expression, since that was thought to be a problem,
> but turns out not to be the case. expr has no problem with newline as
> whitespace.
>
>
>
> --Eric
>
>
>
>
>
>
>
>
>
> On Mon, Oct 20, 2025 at 9:31 AM Colin Macleod via Tcl-Core <
> tcl...@li...> wrote:
>
> I would say {=}{expression} is more Tcl-ish, though two characters
> longer.  It follows the precedent of {*}, and avoids the incompatibility of
> $(expression).  I wonder if that could also be implemented by a simple
> macro-type substitution at the parsing stage, as Eric has proposed.  If {=}
> was TIP-ed I would happily withdraw my competing TIP 676.
>
> Colin.
>
> On 20/10/2025 16:11, da Silva, Peter J wrote:
>
> Obviously I think this is a great idea and I think anyone who actually
> uses $(thing) in production code is crazy, but when I brought it up it got
> shot down because it was apparently found in the wild in production code.
>
>
>
> Pity it didn’t get into 9.0 :) but this would be a good era to do it in.
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
> DISCLAIMER: This message is intended exclusively for the addressee(s) and
> may contain confidential and privileged information. If you are not the
> intended recipient please notify the sender immediately and destroy this
> message. Unauthorized use, disclosure or copying of this message is
> strictly prohibited. The foundation 'Stichting Deltares', which has its
> seat at Delft, The Netherlands, Commercial Registration Number 41146461, is
> not liable in any way whatsoever for consequences and/or damages resulting
> from the improper, incomplete and untimely dispatch, receipt and/or content
> of this e-mail.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

[Arjen M. <Arj...@de...>]

Hi Eric, everyone,

Just for your information: The one extension that I know of that uses an anonymous array is stooop – Simple Tcl-only object-oriented programming – by Jean-Luc Fontaine. It is part of Tcllib.

Regards,

Arjen

From: EricT <tw...@gm...>
Sent: maandag 20 oktober 2025 19:45
To: Colin Macleod <col...@ya...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax

Caution: This message was sent from outside of Deltares. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "Ser...@de...<mailto:Ser...@de...>" as an attachment.

Besides for the jimtcl compatibility and its track record in use, there's another reason I like the $(expr) notation and that is that it acts in all ways like $var, so that what people have learned, such as how to use $ substitution in event callbacks, either by [list puts $var] or {puts $var} depending on whether or not they want delayed evaluation, would be similar for [list puts $(expr)] and {puts $(expr)}.

One other issue that came up in my testing was that my first upload to github a few days ago required that ()'s be balanced in the entire expression, including when there were command callbacks, such as

[string length abc(def]+$n

That would have needed to be escaped as abc\(def, but that restriction has been eliminated in the most recent code in my repository. It turns out that ()'s need to be balanced ONLY in the portions of an expression that are arithmetical, where, for example,  (((1+2))) balancing would be required. The fix is in the latest upload to the repository. This makes it compatible with expr which also does not require balancing of ()'s in command callback strings whether bare or quoted.

One other fix was to eliminate the code that was changing newlines to spaces when found in an expression, since that was thought to be a problem, but turns out not to be the case. expr has no problem with newline as whitespace.

--Eric




On Mon, Oct 20, 2025 at 9:31 AM Colin Macleod via Tcl-Core <tcl...@li...<mailto:tcl...@li...>> wrote:

I would say {=}{expression} is more Tcl-ish, though two characters longer.  It follows the precedent of {*}, and avoids the incompatibility of $(expression).  I wonder if that could also be implemented by a simple macro-type substitution at the parsing stage, as Eric has proposed.  If {=} was TIP-ed I would happily withdraw my competing TIP 676.

Colin.
On 20/10/2025 16:11, da Silva, Peter J wrote:
Obviously I think this is a great idea and I think anyone who actually uses $(thing) in production code is crazy, but when I brought it up it got shot down because it was apparently found in the wild in production code.

Pity it didn’t get into 9.0 :) but this would be a good era to do it in.

_______________________________________________
Tcl-Core mailing list
Tcl...@li...<mailto:Tcl...@li...>
https://lists.sourceforge.net/lists/listinfo/tcl-core
DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail.

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

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

Besides for the jimtcl compatibility and its track record in use, there's
another reason I like the $(expr) notation and that is that it acts in all
ways like $var, so that what people have learned, such as how to use $
substitution in event callbacks, either by [list puts $var] or {puts $var}
depending on whether or not they want delayed evaluation, would be similar
for [list puts $(expr)] and {puts $(expr)}.

One other issue that came up in my testing was that my first upload to
github a few days ago required that ()'s be balanced in the entire
expression, including when there were command callbacks, such as

[string length abc(def]+$n

That would have needed to be escaped as abc\(def, but that restriction has
been eliminated in the most recent code in my repository. It turns out that
()'s need to be balanced ONLY in the portions of an expression that are
arithmetical, where, for example,  (((1+2))) balancing would be required.
The fix is in the latest upload to the repository. This makes it compatible
with expr which also does not require balancing of ()'s in command callback
strings whether bare or quoted.

One other fix was to eliminate the code that was changing newlines to
spaces when found in an expression, since that was thought to be a problem,
but turns out not to be the case. expr has no problem with newline as
whitespace.

--Eric




On Mon, Oct 20, 2025 at 9:31 AM Colin Macleod via Tcl-Core <
tcl...@li...> wrote:

> I would say {=}{expression} is more Tcl-ish, though two characters
> longer.  It follows the precedent of {*}, and avoids the incompatibility of
> $(expression).  I wonder if that could also be implemented by a simple
> macro-type substitution at the parsing stage, as Eric has proposed.  If {=}
> was TIP-ed I would happily withdraw my competing TIP 676.
>
> Colin.
> On 20/10/2025 16:11, da Silva, Peter J wrote:
>
> Obviously I think this is a great idea and I think anyone who actually
> uses $(thing) in production code is crazy, but when I brought it up it got
> shot down because it was apparently found in the wild in production code.
>
>
>
> Pity it didn’t get into 9.0 :) but this would be a good era to do it in.
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

I would say {=}{expression} is more Tcl-ish, though two characters 
longer.  It follows the precedent of {*}, and avoids the incompatibility 
of $(expression).  I wonder if that could also be implemented by a 
simple macro-type substitution at the parsing stage, as Eric has 
proposed.  If {=} was TIP-ed I would happily withdraw my competing TIP 676.

Colin.

On 20/10/2025 16:11, da Silva, Peter J wrote:
>
> Obviously I think this is a great idea and I think anyone who actually 
> uses $(thing) in production code is crazy, but when I brought it up it 
> got shot down because it was apparently found in the wild in 
> production code.
>
> Pity it didn’t get into 9.0 :) but this would be a good era to do it in.
>

Re: [TCLCORE] Report of Biweekly telco on 20th of October at 12:00 UTC

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

OK, here's the follow up. I've been messing around with C11 for a while and have split out the awful mess that was the c-std-update branch into separate, more closely focused branches. These do not cover the full range of what can be done with C11! In some cases, they don't even cover the full range of what we could with the specific feature.

c11-anon-members: Makes some of the nested messes with structs and unions less messy. It's small yet nice.
c11-array-literals: This is another one I like, which makes it so that the places where we define an array of items (often to use with Tcl_NewListObj) are much easier to read.
c11-automarker: This uses C11 variadic macros to add the NULL to the end of Tcl_SetErrorCode; this is likely to be a good thing to adopt into the public API at some point too; it reduces the blunder rate! (Also applies to other APIs that use the same pattern, but Tcl internally doesn't make much use of them.)
c11-bool: This starts the process of adopting the bool type. We need to do more on this. (Note that I've found that passing a bool* instead of an int* or returning a bool instead of an int to be marked as an incompatible API change by various compilers; yuck.)
c11-generic-oo-api: This uses a little magic to make a messy type split in TclOO into something that will be nicer to use.
c11-printf-result: This is a big change, though entirely internal (for now). It uses variadic macros to make a call TclPrintfResult(interp, "pattern", ...), which gets us back to the ease of use for error message generation that Tcl 7 had with sprintf(interp->result, "pattern", ...) except now it's safe against buffer overruns and so on. Currently just for errors, but could be extended elsewhere and also migrated to the public API.
c11-varargs-nr-add-callback: This is another application of C11 variadic macros, this time to allow omission of trailing NULL arguments in the cases where the argument is just a dummy value.

There's more bits to extract (such as the reorganisation of TRACE macros in TEBC) but those are the key ones so far.

Donal.

________________________________
From: Donal Fellows <don...@ma...>
Sent: Monday, October 20, 2025 16:43
To: Harald Oehlmann <har...@el...>; Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] Report of Biweekly telco on 20th of October at 12:00 UTC

I'll talk about this more in a follow-up message.

Re: [TCLCORE] Report of Biweekly telco on 20th of October at 12:00 UTC

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

Some comments on some of these items as I couldn't make the telcon:

1. Release calendar sounds like a good plan, and I'm happy that it is going well. (Assume from here on that if I don't comment on things, I'm just being generally approving of the way that discussion is going.)
3. Accessibility is quite a requirement (and is something I get pushed on at work), and yet it is often difficult to pin down how to make Tk better at it (or indeed how to integrate with often ill-documented systems put forward for the purpose). That someone's grasped this nettle is great! I approve a lot. The trickiness of the area reminds me of Input Methods, where the explanations were usually completely incomprehensible as well as impossible to implement...
5. The C enums stuff should be fine; enum values are ints (if they fit in the int range) so the few cases where we don't want an int need something else. I think I've accounted for all of that. Also, cases where we expect that users might want to redefine things on the command line in a build (such as overriding a macro definition to get a different buffer length) are inappropriate, as are anything that needs to be processed by the resource compiler (fortunately not too many things). Overall there's two basic cases where things are suitable: sequences of things (such as Tcl_QueuePosition in tcl.h), and bitmasks (e.g., InterpFlags in tclInt.h); both of those cases work fine in all compilers I've ever seen.
6. For the new bytecodes, the only real disruption is the new auxiliary data type. Everything else is super low chance to cause any problems (as the code that has the problem is already delving in deep into the guts of Tcl where we don't give compatibility promises by policy). I make no promises to not introduce further bytecodes as 9.1 progresses; I've been trialling one for the guts of namespace parent, but that gets a bit messy in one awful edge case. Yuck.
8. It's absolutely great that we're moving to C11 as a minimum language profile! I've a number of branches that highlight things we could do with this. I'll talk about this more in a follow-up message. The ancient systems with ancient build requirements... are just a mess to support, especially as using a more recent compiler may well generate better code. (I've seen this directly for gcc when building for embedded ARM, where newer compiler versions produced significantly more compact code, enough that we could stop requiring icc for building that particular codebase...)
9. The key problem with the $(expr) syntax is that it definitely breaks existing code, specifically stooop <https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tcllib/files/modules/stooop/stooop.md> (i.e., tcllib). Otherwise a good idea. Do we have any idea how many stooop users there are?

Donal.

________________________________
From: Harald Oehlmann <har...@el...>
Sent: Monday, October 20, 2025 14:30
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] Report of Biweekly telco on 20th of October at 12:00 UTC

Dear Tcl/Tk team,

here is the report of the biweekly telco of today:

Top 1) Release calender (TIP 713)
- 9.0.3: October (2 weeks left)
SQLite 2.15.1 is planned for in 2 weeks. Might be useful to wait for it
Tdbc-sqlite dict extension by Christian may be in a later release. This
is the foundation.
- 9.1a1: November (6 weeks left)

Top 3) TIP 733: accessability (test status)
Highly appreciated. Tests should pass.
Important for alpha release, as testing is required. People must test
the feature.
There are historic Tk test files for interactive testing. That would be
a path to test this feature.
People will test.

Top 5) TIP 731: use C enums (no brainer?)
enums is prefered, great work !
In addition, compiler can check more cases (case strctures).

Little chance for incompatibility, as check for existence (#ifdef)
changes. Should be in the compatibility section of the TIP.

Not all participants are convinced, if bitmasks are good as enums.
Compiler knows the maximum value, if assigned to an int.

Top 6) TIP 720: new bytecodes (final, great! Any issues?)
Its a risk as disruptive change.
Highly appreciated.

Top 8) TIP 715: supported build systems
Tcl 9.0 currently has minimum C11, with exception of MS-VS 2015 (limited
implementation)

Old industrial systems controls require older compilers.
2038 will put a hard end on Tcl 8.6.

Top 9) $($a+$b) syntax for expressions
Thanks for the great contribution.
Incompatibility is seen as critical.
Breaking change, only for version 10.
Only possible in tcl 9 with global nob.
Impact on constructed code will cause error cases hard to find.
Proposal with "{=}{$a+$b}" would not break basic syntax rules.

Jim compatibility is seen as relevant.
That is a plus point.
Test suite with patch is clean!
Discussion may continue.

Top 10) Tk test reform by Eric (Thanks !)
Appreciated. No discussion due to lack of time

Top 11) Tcl depot and awthemes ?
Skipped, timeout
Top 12) AOB
Skipped, timeout
Top 13) Next meeting:
     3rd of November 12:00 UTC.

Thanks for all,
Harald

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

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

Obviously I think this is a great idea and I think anyone who actually uses $(thing) in production code is crazy, but when I brought it up it got shot down because it was apparently found in the wild in production code.

Pity it didn’t get into 9.0 :) but this would be a good era to do it in.

From: EricT <tw...@gm...>
Date: Monday, October 20, 2025 at 10:05
To: da Silva, Peter J (USA) <pet...@fl...>
Cc: tc...@ro... <tc...@ro...>, tcl...@li... <tcl...@li...>, et...@ro... <et...@ro...>
Subject: Re: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax
Hi Peter, I sent you an email, but my email program keeps failing for some reason, so I'll repost what I said here. There's also apparently a delay in seeing the email here that caused me to reply from my home email. Yes, that is the

Hi Peter,

I sent you an email, but my email program keeps failing for some reason, so I'll repost what I said here. There's also apparently a delay in seeing the email here that caused me to reply from my home email.

Yes, that is the one known incompatibility I'm aware of. However, it is easily fixed. Please note my email to the core group on this subject. Briefly, the fix is to use the ${(index)} feature that is a compatible mechanism which can be made immediately. With the use of a pragma variable, the code could be set to throw an error for any $() usage to help track down all the unbraced usage for fixing.

Here's some testing with the feature enabled:

  % set a 1
1
  % set b 2
2
  % set c $($a+$b)
3
  % set (index) something
something
  % set (index)
something
  % puts ${(index)}
something
  % puts $(index)
invalid bareword "index"
in expression "index";
should be "$index" or "{index}" or "index(...)" or ...

This is without implementing any pragma. So, it could already find many unbraced uses.

Regards,

Eric



On Mon, Oct 20, 2025 at 7:38 AM da Silva, Peter J <pet...@fl...<mailto:pet...@fl...>> wrote:
I recall that on one occasion when I suggested this kind of syntax I was told there was working code that used $(...) as an array index for an array whose name was the null string.

From: EricT <tw...@gm...<mailto:tw...@gm...>>
Date: Friday, October 17, 2025 at 16:23
To: tcl...@li...<mailto:tcl...@li...> <tcl...@li...<mailto:tcl...@li...>>
Cc: et...@ro...<mailto:et...@ro...> <et...@ro...<mailto:et...@ro...>>
Subject: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax
Hello Tcl Core Team, I have developed a working prototype implementation of TIP 672, which adds the $(expression) syntax as a more intuitive alternative to [expr {expression}]. Repository: https: //github. com/rocketship88/tcl-tip-672-prototype
Hello Tcl Core Team,

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

Repository: https://github.com/rocketship88/tcl-tip-672-prototype<https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=lqqkjbudEIhZyWU1Mr-DT_aw0n-0q0fJeE2A7RRQpS2HwF0EA62yINzmRaXGPetk&s=S65xARxittuq7tg4WiuXdT0ervfhA8RXzsEv3-NxhGA&e=>

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

Key Accomplishments:

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

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

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

Known Limitations:

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

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

Questions for the Team:

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

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

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

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

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

Hi Peter,

I sent you an email, but my email program keeps failing for some reason, so
I'll repost what I said here. There's also apparently a delay in seeing the
email here that caused me to reply from my home email.

Yes, that is the one known incompatibility I'm aware of. However, it is
easily fixed. Please note my email to the core group on this subject.
Briefly, the fix is to use the ${(index)} feature that is a compatible
mechanism which can be made immediately. With the use of a pragma variable,
the code could be set to throw an error for any $() usage to help track
down all the unbraced usage for fixing.

Here's some testing with the feature enabled:

  % set a 1
1
  % set b 2
2
  % set c $($a+$b)
3
  % set (index) something
something
  % set (index)
something
  % puts ${(index)}
something
  % puts $(index)
invalid bareword "index"
in expression "index";
should be "$index" or "{index}" or "index(...)" or ...

This is without implementing any pragma. So, it could already find many
unbraced uses.

Regards,

Eric



On Mon, Oct 20, 2025 at 7:38 AM da Silva, Peter J <
pet...@fl...> wrote:

> I recall that on one occasion when I suggested this kind of syntax I was
> told there was working code that used $(...) as an array index for an array
> whose name was the null string.
>
>
>
> *From: *EricT <tw...@gm...>
> *Date: *Friday, October 17, 2025 at 16:23
> *To: *tcl...@li... <tcl...@li...>
> *Cc: *et...@ro... <et...@ro...>
> *Subject: *[TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax
>
> Hello Tcl Core Team, I have developed a working prototype implementation
> of TIP 672, which adds the $(expression) syntax as a more intuitive
> alternative to [expr {expression}]. Repository: https: //github.
> com/rocketship88/tcl-tip-672-prototype
>
> Hello Tcl Core Team,
>
> I have developed a working prototype implementation of TIP 672, which adds
> the $(expression) syntax as a more intuitive alternative to [expr
> {expression}].
>
> Repository: https://github.com/rocketship88/tcl-tip-672-prototype
> <https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=lqqkjbudEIhZyWU1Mr-DT_aw0n-0q0fJeE2A7RRQpS2HwF0EA62yINzmRaXGPetk&s=S65xARxittuq7tg4WiuXdT0ervfhA8RXzsEv3-NxhGA&e=>
>
> The implementation is minimal, modifying only two files (tclParse.c and
> tclNamesp.c) with approximately 100 lines of changes. The key modification
> converts the existing two-way branch in Tcl_ParseVarName to a three-way
> branch, with the new path handling $(...) by creating a synthetic [expr
> {...}] command string.
>
> Key Accomplishments:
>
> Full bytecode compilation: The synthetic string approach integrates
> seamlessly with the existing compiler, producing identical optimized
> bytecode as [expr {...}]. The disassembler output (shown in the README)
> demonstrates efficient variable loading with no runtime parsing overhead.
>
> Proven approach: Jim Tcl has used this syntax successfully for years
>
> Comprehensive testing: Works correctly with string interpolation, variable
> scoping, error handling, and interactive mode
>
> Known Limitations:
>
> Memory leak: The synthetic string is allocated but not tracked for cleanup
> in Tcl_FreeParse. This requires core team guidance on the preferred
> solution (modify Tcl_Parse structure vs. thread-local tracking).
>
> Error messages: Currently show the synthetic command rather than the
> original $(...) syntax, though this is arguably helpful for debugging.
>
> Questions for the Team:
>
> What is the preferred approach for tracking synthetic strings for cleanup?
> Is this prototype architecture acceptable for Tcl 9.x?
> Are there concerns with the synthetic string approach that I should
> address?
>
> The complete implementation with side-by-side diffs is available in the
> repository. I'm happy to refine the code based on your feedback and would
> appreciate any guidance on moving this forward.
>
> Best regards,
> Eric
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

I recall that on one occasion when I suggested this kind of syntax I was told there was working code that used $(...) as an array index for an array whose name was the null string.

From: EricT <tw...@gm...>
Date: Friday, October 17, 2025 at 16:23
To: tcl...@li... <tcl...@li...>
Cc: et...@ro... <et...@ro...>
Subject: [TCLCORE] Prototype Implementation of TIP 672 - $(expr) Syntax
Hello Tcl Core Team, I have developed a working prototype implementation of TIP 672, which adds the $(expression) syntax as a more intuitive alternative to [expr {expression}]. Repository: https: //github. com/rocketship88/tcl-tip-672-prototype

Hello Tcl Core Team,

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

Repository: https://github.com/rocketship88/tcl-tip-672-prototype<https://urldefense.us/v2/url?u=https-3A__github.com_rocketship88_tcl-2Dtip-2D672-2Dprototype&d=DwMFaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=lqqkjbudEIhZyWU1Mr-DT_aw0n-0q0fJeE2A7RRQpS2HwF0EA62yINzmRaXGPetk&s=S65xARxittuq7tg4WiuXdT0ervfhA8RXzsEv3-NxhGA&e=>

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

Key Accomplishments:

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

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

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

Known Limitations:

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

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

Questions for the Team:

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

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

Best regards,
Eric

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

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

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

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

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

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

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

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

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

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

to

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

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

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

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

thanks

Eric


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

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

[TCLCORE] Report of Biweekly telco on 20th of October at 12:00 UTC

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

Dear Tcl/Tk team,

here is the report of the biweekly telco of today:

Top 1) Release calender (TIP 713)
- 9.0.3: October (2 weeks left)
SQLite 2.15.1 is planned for in 2 weeks. Might be useful to wait for it
Tdbc-sqlite dict extension by Christian may be in a later release. This 
is the foundation.
- 9.1a1: November (6 weeks left)

Don faces work issues like most US gouvernment organs, which may end at 
each moment, but no prediction possible.
Jan joins the release team and will jump-in in coordination with Don.

Current release timing is seen as reasonable.

Top 2) TIP 734 nested mutex (go or not)
We did a lot of efforts to make it work.
We have test cases.
The reason to remove it is not there any more.
Wait for Ashok, unfortunately not present today.
Sebres and Christian are very reserved on this feature.
Use case is the encoding initialisation of TCL.
We want consistent behaviour on all platforms.
Windows works, Linux may hang in rare cases.
The TIP proposes to go back to 8.6, what is currently in inconsistent 
state (work on Windows, not on Linux).

The API encourages to go the wrong way (nested mutex). But the rare case 
where it is useful is good.

Splitting the API in two versions would be ok (recursive and 
non-recursive). But there is no error path if the mutex is already locked.

A warning should be added to the documentation that recursive mutex is 
bad design.

The main reason for TIP 509 was consistent behaviour, as Windows did it.
- two possible consistent behahaviors for mutex lock when mutex is locked:
   - recursive
   - panic
Currently, there is no error path

Top 3) TIP 733: accessability (test status)
Highly appreciated. Tests should pass.
Important for alpha release, as testing is required. People must test 
the feature.
There are historic Tk test files for interactive testing. That would be 
a path to test this feature.
People will test.

Top 4) TIP 732: TCL library path (discussion)
To many things in the library path. Any improvement welcomed.
Make the rc file configurable.

Using external files and environment variables is also a security risk.
It would be great to make this configurable.
Tk also concerned.

Top 5) TIP 731: use C enums (no brainer?)
enums is prefered, great work !
In addition, compiler can check more cases (case strctures).

Little chance for incompatibility, as check for existence (#ifdef) 
changes. Should be in the compatibility section of the TIP.

Not all participants are convinced, if bitmasks are good as enums.
Compiler knows the maximum value, if assigned to an int.

Top 6) TIP 720: new bytecodes (final, great! Any issues?)
Its a risk as disruptive change.
Highly appreciated.

Top 7) TIP 721: Tcl_AttemptGetString
Not finished jet. Need some more functions.
Highly appreciated.

Top 8) TIP 715: supported build systems
Tcl 9.0 currently has minimum C11, with exception of MS-VS 2015 (limited 
implementation)

Old industrial systems controls require older compilers.
2038 will put a hard end on Tcl 8.6.

Top 9) $($a+$b) syntax for expressions
Thanks for the great contribution.
Incompatibility is seen as critical.
Breaking change, only for version 10.
Only possible in tcl 9 with global nob.
Impact on constructed code will cause error cases hard to find.
Proposal with "{=}{$a+$b}" would not break basic syntax rules.

Jim compatibility is seen as relevant.
That is a plus point.
Test suite with patch is clean!
Discussion may continue.

Top 10) Tk test reform by Eric (Thanks !)
Appreciated. No discussion due to lack of time

Top 11) Tcl depot and awthemes ?
Skipped, timeout
Top 12) AOB
Skipped, timeout
Top 13) Next meeting:
     3rd of November 12:00 UTC.

Thanks for all,
Harald

Re: [TCLCORE] Binary installer for macOS

[Marc C. <cul...@gm...>]

Hi Nicolas,

Thanks for trying out the installer!

Putting Wish.app in the Resources directory and creating symlinks in
/usr/local/bin is not some weird thing that I just invented.  That is
exactly what happens with a standard framework build.  In fact, the Tcl and
Tk packages which are embedded in the full installer package are created by
simply archiving the frameworks built by a standard framework build.  It is
correct that the installer is fat - it supports intel with an install
target of 10.13 and arm with an install target of 11.0.  I do not think
that /usr/local is an appropriate location for an app bundle.  I have never
seen that before.

It looks like the issues which you are running into when building your app
arise from trying to embed signed and notarizes code into your app, poaibly
without resigning it. (I can't tell exactly what is involved with your
build process.)  It also looks like your build process maybe changing dylib
load paths, which destroys the signature, without resigning the enclosing
framework.

That is not really the intended application of the installer.  If you are
building an app with an embedded Tk you are probably better off building Tk
as well and handling the signing and notarization process at the level of
your app - signing all executable files, then signing all frameworks, then
signing the app, then notarizing the app, then repackaging the notarized
app in a new disk image, then notarizing that disk image.

The intended use of the installer is for people who just want to run tclsh
or wish, possibly with additional extension packages.  The package is
notarized to make the installation process smoother, without having to
remove quarantine xattrs or change system settings.

- Marc


On Sun, Oct 19, 2025 at 5:26 AM nicolas bats <sl1...@gm...> wrote:

> Hi Marc,
> I've tried the standard way of the installer. everything is installed
> under /Library/Frameworks.
> Two alias for tclsh9.1 and wish9.1 are also created in /usr/local/bin
>
> here's what is inside Tk:
>
> nico@mac ~ % cd /Library/Frameworks/Tk.framework/Versions/9.1
>
> nico@mac 9.1 % ls
>
> _CodeSignature libtkstub.a PrivateHeaders Tk wish9.1
>
> Headers pkgconfig Resources tkConfig.sh
>
> nico@mac 9.1 %
>
>
> wish9.1 is a fat file:
>
> nico@mac 9.1 % file wish9.1
>
> wish9.1: Mach-O universal binary with 2 architectures: [x86_64:Mach-O
> 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
>
> wish9.1 (for architecture x86_64): Mach-O 64-bit executable x86_64
>
> wish9.1 (for architecture arm64): Mach-O 64-bit executable arm64
>
>
> and signature works
>
> nico@mac 9.1 % codesign -dv wish9.1
>
> Executable=/Library/Frameworks/Tk.framework/Versions/9.1/wish9.1
>
> Identifier=com.tcltk.wish
>
> Format=Mach-O universal (x86_64 arm64)
>
> CodeDirectory v=20500 size=506 flags=0x10000(runtime) hashes=5+7
> location=embedded
>
> Signature size=8972
>
> Timestamp=13 Oct 2025 at 17:08:03
>
> Info.plist entries=20
>
> TeamIdentifier=A3LBEGBB69
>
> Runtime Version=26.0.0
>
> Sealed Resources=none
>
> Internal requirements count=1 size=176
>
>
> but on my computer running macOS26 wish9.1 is identified as a document
> file, not as an app that I can run
>
> so I went to Resources where the is a Wish.app.
>
>
> running this one (double-click on Wish) prints this error:
>
> invalid command name "ttk::toggleswitch::CondUpdateElements"
>     while executing
> "ttk::toggleswitch::CondUpdateElements"
> () 1 %
>
>
> and file/Run Widget demo is not accessible
>
>
> after I've tried to link my app against installed Tcl.framework and
> Tk.framework and it fails.
>
> here's what my script is saying:
>
> -- fixup_bundle: fixing...
>
> -- 27/52: fixing up
> '/Users/nico/daylight/build/DLight.app/Contents/MacOS/DLight'
>
> -- 28/52: fixing up
> '/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tcl.framework/Versions/9.1/Tcl'
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
> warning: changes being made to the file will invalidate the code signature
> in:
> /Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tcl.framework/Versions/9.1/Tcl
> (for architecture x86_64)
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
> warning: changes being made to the file will invalidate the code signature
> in:
> /Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tcl.framework/Versions/9.1/Tcl
> (for architecture arm64)
>
> -- 29/52: fixing up
> '/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Tk'
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
> warning: changes being made to the file will invalidate the code signature
> in:
> /Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Tk
> (for architecture x86_64)
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
> warning: changes being made to the file will invalidate the code signature
> in:
> /Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Tk
> (for architecture arm64)
>
>
> then:
>
> -- executable file 1:
> /Users/nico/daylight/build/DLight.app/Contents/MacOS/DLight
>
> -- executable file 2:
> /Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish.app/Contents/MacOS/Wish
> Shell
>
> -- executable file 3:
> /Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish.app/Contents/MacOS/Wish
>
> -- executable file 4:
> /Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish
> Shell.app/Contents/MacOS/Wish Shell
>
> -- executable file 5:
> /Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish
> Shell.app/Contents/MacOS/Wish
>
> -- verified='0'
>
> -- info='external prerequisites found:
>
> f='/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish.app/Contents/MacOS/Wish
> Shell'
>
>
> external_prereqs='/Library/Frameworks/Tcl.framework/Versions/9.1/Tcl;/Library/Frameworks/Tk.framework/Versions/9.1/Tk'
>
> ;external prerequisites found:
>
>
> f='/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish.app/Contents/MacOS/Wish'
>
>
> external_prereqs='/Library/Frameworks/Tcl.framework/Versions/9.1/Tcl;/Library/Frameworks/Tk.framework/Versions/9.1/Tk'
>
> ;external prerequisites found:
>
> f='/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish
> Shell.app/Contents/MacOS/Wish Shell'
>
>
> external_prereqs='/Library/Frameworks/Tcl.framework/Versions/9.1/Tcl;/Library/Frameworks/Tk.framework/Versions/9.1/Tk'
>
> ;external prerequisites found:
>
> f='/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish
> Shell.app/Contents/MacOS/Wish'
>
>
> external_prereqs='/Library/Frameworks/Tcl.framework/Versions/9.1/Tcl;/Library/Frameworks/Tk.framework/Versions/9.1/Tk'
>
> '
>
> --
>
> CMake Error at
> /usr/local/share/cmake-3.31/Modules/BundleUtilities.cmake:1127 (message):
>
>   error: verify_app failed
>
> Call Stack (most recent call first):
>
>   /usr/local/share/cmake-3.31/Modules/BundleUtilities.cmake:994
> (verify_app)
>
>   cmake_install.cmake:174 (fixup_bundle)
>
>
> so it seems that for me the installer isn't good because of wish / wish
> shell presence inside the Framework.
>
> Can you locate them in /usr/local/bin instead of inside the framework?
>
>
> hope this helps,
>
> best regards,
>
> nicolas
>
>
>
>
> Le dim. 19 oct. 2025 à 04:47, Marc Culler <cul...@gm...> a écrit :
>
>> I have been working on a binary installer for Tcl, Tk and selected
>> extension packages.  I would be interested in any feedback that people can
>> provide after trying it out.
>>
>> You can download the signed and notarized Installer package here:
>>
>> https://github.com/culler/tcltk_pkg/releases/download/v0.0-alpha/tcltk9.1.pkg
>>
>> - Marc
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>

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

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

Harald,

Thank you for your willingness to sponsor!

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

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

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

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

Looking forward to hearing how Monday's discussion goes!

Best regards,
Eric


On Sun, Oct 19, 2025 at 2:05 AM Harald Oehlmann <har...@el...>
wrote:

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

Re: [TCLCORE] Binary installer for macOS

[nicolas b. <sl1...@gm...>]

Hi Marc,
I've tried the standard way of the installer. everything is installed under
/Library/Frameworks.
Two alias for tclsh9.1 and wish9.1 are also created in /usr/local/bin

here's what is inside Tk:

nico@mac ~ % cd /Library/Frameworks/Tk.framework/Versions/9.1

nico@mac 9.1 % ls

_CodeSignature libtkstub.a PrivateHeaders Tk wish9.1

Headers pkgconfig Resources tkConfig.sh

nico@mac 9.1 %


wish9.1 is a fat file:

nico@mac 9.1 % file wish9.1

wish9.1: Mach-O universal binary with 2 architectures: [x86_64:Mach-O
64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]

wish9.1 (for architecture x86_64): Mach-O 64-bit executable x86_64

wish9.1 (for architecture arm64): Mach-O 64-bit executable arm64


and signature works

nico@mac 9.1 % codesign -dv wish9.1

Executable=/Library/Frameworks/Tk.framework/Versions/9.1/wish9.1

Identifier=com.tcltk.wish

Format=Mach-O universal (x86_64 arm64)

CodeDirectory v=20500 size=506 flags=0x10000(runtime) hashes=5+7
location=embedded

Signature size=8972

Timestamp=13 Oct 2025 at 17:08:03

Info.plist entries=20

TeamIdentifier=A3LBEGBB69

Runtime Version=26.0.0

Sealed Resources=none

Internal requirements count=1 size=176


but on my computer running macOS26 wish9.1 is identified as a document
file, not as an app that I can run

so I went to Resources where the is a Wish.app.


running this one (double-click on Wish) prints this error:

invalid command name "ttk::toggleswitch::CondUpdateElements"
    while executing
"ttk::toggleswitch::CondUpdateElements"
() 1 %


and file/Run Widget demo is not accessible


after I've tried to link my app against installed Tcl.framework and
Tk.framework and it fails.

here's what my script is saying:

-- fixup_bundle: fixing...

-- 27/52: fixing up
'/Users/nico/daylight/build/DLight.app/Contents/MacOS/DLight'

-- 28/52: fixing up
'/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tcl.framework/Versions/9.1/Tcl'

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
warning: changes being made to the file will invalidate the code signature
in:
/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tcl.framework/Versions/9.1/Tcl
(for architecture x86_64)

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
warning: changes being made to the file will invalidate the code signature
in:
/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tcl.framework/Versions/9.1/Tcl
(for architecture arm64)

-- 29/52: fixing up
'/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Tk'

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
warning: changes being made to the file will invalidate the code signature
in:
/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Tk
(for architecture x86_64)

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
warning: changes being made to the file will invalidate the code signature
in:
/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Tk
(for architecture arm64)


then:

-- executable file 1:
/Users/nico/daylight/build/DLight.app/Contents/MacOS/DLight

-- executable file 2:
/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish.app/Contents/MacOS/Wish
Shell

-- executable file 3:
/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish.app/Contents/MacOS/Wish

-- executable file 4:
/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish
Shell.app/Contents/MacOS/Wish Shell

-- executable file 5:
/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish
Shell.app/Contents/MacOS/Wish

-- verified='0'

-- info='external prerequisites found:

f='/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish.app/Contents/MacOS/Wish
Shell'

external_prereqs='/Library/Frameworks/Tcl.framework/Versions/9.1/Tcl;/Library/Frameworks/Tk.framework/Versions/9.1/Tk'

;external prerequisites found:

f='/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish.app/Contents/MacOS/Wish'

external_prereqs='/Library/Frameworks/Tcl.framework/Versions/9.1/Tcl;/Library/Frameworks/Tk.framework/Versions/9.1/Tk'

;external prerequisites found:

f='/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish
Shell.app/Contents/MacOS/Wish Shell'

external_prereqs='/Library/Frameworks/Tcl.framework/Versions/9.1/Tcl;/Library/Frameworks/Tk.framework/Versions/9.1/Tk'

;external prerequisites found:

f='/Users/nico/daylight/build/DLight.app/Contents/Frameworks/Tk.framework/Versions/9.1/Resources/Wish
Shell.app/Contents/MacOS/Wish'

external_prereqs='/Library/Frameworks/Tcl.framework/Versions/9.1/Tcl;/Library/Frameworks/Tk.framework/Versions/9.1/Tk'

'

-- 

CMake Error at
/usr/local/share/cmake-3.31/Modules/BundleUtilities.cmake:1127 (message):

  error: verify_app failed

Call Stack (most recent call first):

  /usr/local/share/cmake-3.31/Modules/BundleUtilities.cmake:994 (verify_app)

  cmake_install.cmake:174 (fixup_bundle)


so it seems that for me the installer isn't good because of wish / wish
shell presence inside the Framework.

Can you locate them in /usr/local/bin instead of inside the framework?


hope this helps,

best regards,

nicolas




Le dim. 19 oct. 2025 à 04:47, Marc Culler <cul...@gm...> a écrit :

> I have been working on a binary installer for Tcl, Tk and selected
> extension packages.  I would be interested in any feedback that people can
> provide after trying it out.
>
> You can download the signed and notarized Installer package here:
>
> https://github.com/culler/tcltk_pkg/releases/download/v0.0-alpha/tcltk9.1.pkg
>
> - Marc
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

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

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

Eric,
sponsoring is no problem. The point is to get positive votes.
This requires a positive discussion.
You are the Author of Jim?
Could you participate on the telco on Monday?

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

Thanks for all,
Harald

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