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

[Zaumseil R. <RZa...@kk...>]

+1 on propagating [= …] vs $(..). Using $(..) as command needs additional explanation.

Von: Florent Merlet <flo...@gm...>
Gesendet: Mittwoch, 22. Oktober 2025 07:31
An: Donal Fellows <don...@ma...>; tcl...@li...
Betreff: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax


Donal,

Another level is the C source level, whose clarity of code is important too : New generations will learn Tcl in the future.

On this point of view, does the implementation of the expression shorthand in a procedure whose name is « Tcl_ParseVarname » look so wonderfull ?

There is already a way to compute a expression in a string, it's through the command substitution []

with : interp alias {} "=" {} expr

% string range "abcdef" 1 end-[= 3-2]

But now, is there really a necessity to pollute the "$" substitution procedure as well, to be able to write :

% string range "abcdef" 1 end-$(3-2)

Semantically, « expression substitution » is more like « command substitution » than like « variable substitution ». That's why, Eric, in his change in Tcl_ParseVarname, has to « transmute » the TCL_TOKEN_VARIABLE into a TCL_TOKEN_COMMAND. Now, Tcl_ParseVarname can return either TCL_TOKEN_VAR, TCL_TOKEN_TEXT or TCL_TOKEN_COMMAND.

The logic is not beautifull. Semantically, the good place for any change like this must be in Tcl_ParseToken, and must rely on the concept of « expression substitution » which has to return a TCL_TOKEN_EXPRESSION

The question is : on what char(s) make that detection ?

why not on the equal sign ?

% string range "abcdef" 1 end-{=}3-2

Ok, its bracketment is not very readable.

For this bracketment, it remains unicode chars

% string range "abcdef" 1 end-⟦3-2⟧

With its ascii variant :

% string range "abcdef" 1 end-[|3-2|]



Florent
Le 21/10/2025 à 23:18, Donal Fellows a écrit :
We can match all sorts of things. What matters is what we should match. What is in play is how much of a syntactic incompatibility we are willing to stomach. If we decide that we are rejecting any syntax changes that could possibly have a compatibility impact, we have only the option to reject all change.

The key thing that we are looking for here is to be a syntactic alternative for [expr {expression...}], which has many potential uses. The option with {=} has the disadvantage of not being naturally bracketed unless written as {=}{expression...} and that's just not the nicest thing (for {*}, we were dealing with reinterpretation of words, with the freedom and restrictions that implies, but that's not in play here), and gets ugly when used in the interior of a word. The options with $(expression...) and $((expression...)) are much less of a problem in that regard... but have more potential for compatibility problems. (These are non-theoretical issues for the $(expression...) form, which is definitely in use in the wild; we have found many examples, even if we've not yet worked out if they're truly a problem in all cases.)

Exactly which code should be adapted once we decide what the language change should be... is just a simple matter of changing what needs changing. In terms of commands affected, I can predict this will have an impact inside subst primarily, and possibly assemble; I see no need to add it to the expression language.

Note of course that expressions are expected to syntactically have balanced parentheses (except for comments).

Donal.

-------- Original message --------
From: Florent Merlet <flo...@gm...><mailto:flo...@gm...>
Date: 21/10/2025 20:01 (GMT+00:00)
To: tc...@ro...<mailto:tc...@ro...>
Cc: tcl...@li...<mailto:tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax

Why not ? {=} can be check in Tcl_ParseToken.
--
________________________________
Florent MERLET
4 rue Johann Strauss
Logement 7
86180 BUXEROLLES
________________________________
Mél. : flo...@gm...<mailto:flo...@gm...>
Tél. : 06 70 00 63 48