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

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

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...>
> Date: 21/10/2025 20:01 (GMT+00:00)
> To: tc...@ro...
> Cc: tcl...@li...
> Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - 
> $(expr) Syntax
>
> Why not ? {=} can be check in Tcl_ParseToken.
>
-- 
------------------------------------------------------------------------
*Florent MERLET*
/4 rue Johann Strauss
Logement 7
86180 BUXEROLLES/
------------------------------------------------------------------------
*Mél.* : /flo...@gm.../
*Tél.* : /06 70 00 63 48/