Menu
▾
▴
Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
|
From: Colin M. <col...@ya...> - 2025-10-22 15:31:24
|
Ok but if you just alias = to expr you're vulnerable to various gotchas and unnecessary shimmering of values unless you also brace the expression - https://wiki.tcl-lang.org/page/Brace+your+expr%2Dessions. So you need to write [= {$x-2}] which is an improvement with no compatibility issues, and is only one character longer than $(($x-2)). It's also the same length as [= $x - 2] which is how that would need to be written under my proposal. I think mine is slightly more readable, but the differences are marginal. Using $($x-2) is certainly neater but seems to be disliked on compatibility grounds. So if we come down to a choice between [= {expression}] and $((expression)) it's hard to see enough benefit to justify a radical new feature. Colin. On 22/10/2025 14:49, da Silva, Peter J wrote: > > 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... > *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... > > 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/ > > > > > _______________________________________________ > > Tcl-Core mailing list > > 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=> > |
