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

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

I don’t think it’s reasonable to try and make random language elements immune to upstream metacharacter injection attacks. You have to treat untrusted user input as hostile when you write the code.

I really like the idea of making = an alias for expr, it solves the verbosity issue without introducing new syntax. And if it’s added as a standard language convention it won’t be surprising.

From: Colin Macleod via Tcl-Core <tcl...@li...>
Date: Wednesday, October 22, 2025 at 04:43
To: tcl...@li... <tcl...@li...>
Subject: Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
Hi All, perhaps it's time to boost my own expr proposal again. I like the [= <expr>] idea, but simply aliasing "=" to expr doesn't help much because you still need to brace the expression to avoid double-substitution problems. Unbraced


Hi All, perhaps it's time to boost my own expr proposal again.

I like the [= <expr>] idea, but simply aliasing "=" to expr doesn't help much because you still need to brace the expression to avoid double-substitution problems.  Unbraced works ok for the simple examples Florent gives, but in general is problematic, e.g.

set x {[exec cat /secret/file >/dev/tty]}    ;# x might be set from user input
...
string range "abcdef" 1 end-[= $x-2]      ;# user sees secret file :-(

My own TIP 676 is a proposal to make [= <expression>] usable and safe.  It has the advantage of not requiring any change to the dodekalogue and is fully compatible with existing code.  It also can be used anywhere that [] gets expanded including within quoted strings, which is not the case for the {=}{expr} proposal.

There are some downsides:
- Operators and operands need to be separated with spaces, i.e.  [= $x - 2]  not  [= $x-2]
- Only numerical and boolean values can be supported, not string values
- Lazy evaluation of && || ?: is not supported
- The implementation is a little more complicated since it can't use the existing [expr] parser.  I supplied a Tcl prototype, linked from the TIP, actual implementation would require translating this into C.

I worked on this in 2023 but put it aside because everyone was focussed on getting 9.0 released, then I moved on to a different project.  I think it's worth considering now that [expr] simplification is back in the spotlight.

Colin.
On 22/10/2025 09:05, Zaumseil René via Tcl-Core wrote:
+1 on propagating [= …] vs $(..). Using $(..) as command needs additional explanation.

Von: Florent Merlet <flo...@gm...><mailto:flo...@gm...>
Gesendet: Mittwoch, 22. Oktober 2025 07:31
An: Donal Fellows <don...@ma...><mailto:don...@ma...>; tcl...@li...<mailto: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




_______________________________________________

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=DwMDaQ&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=qlVAdTeNR2-pXS3j_2QUxkwF-zAnAKn280uiCTQxlrKGO8FXb5HwJAg-GzNklZ3F&s=vLrLLZ6yEAxV7iIdm5yDVWuwhmj4EgIJ7-td44Tk_o0&e=>