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

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

I believe that

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

is not actually true.  With 9.0:

$ /usr/local/bin/tclsh9.0

% array set {} { (index) 99 }

% puts $((index))

invalid character in array index

%

or

% /usr/local/bin/tclsh9.0

% array set {} { (index 99 }

% puts $((index)

invalid character in array index


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


In the first case:


% puts $(\(index\))

99


or in the second case:


% puts $(\(index)

99

%

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

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

Phil

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

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