Menu
▾
▴
Re: [TCLCORE] [Ext] Prototype Implementation of TIP 672 - $(expr) Syntax
|
From: Colin M. <col...@ya...> - 2025-10-22 09:41:53
|
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...>
> *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...
>
> 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 |
