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

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

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

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

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

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

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

Thanks all,
Eric



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

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