Menu
▾
▴
tcl-core
|
From: Donal F. <don...@ma...> - 2025-10-21 21:18:27
|
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.
|
|
From: EricT <tw...@gm...> - 2025-10-21 22:00:45
|
Donald:
Donal:
Thanks for the feedback! I appreciate both perspectives on this.
Both approaches have merit. $= avoids compatibility issues entirely, while
$(...) is more intuitive and has shell precedent. I've implemented both -
happy to go with whatever the core team decides.
Donald's suggestion of using a non-conflicting character would allow the
feature to go directly into 9.x without any compatibility concerns or
pragma mechanism. On the other hand, Donal's preference for $(...)
maintains the cleaner syntax with shell familiarity, and the pragma
approach provides a reasonable migration path for the empty array edge case.
If it would be helpful, I could set up the implementation with compile-time
options to support both mechanisms simultaneously, making it easy to test
and compare both approaches.
Either way, I'm ready to move forward with whichever direction the team
feels is best for Tcl.
Eric
On Tue, Oct 21, 2025 at 2:18 PM Donal Fellows <
don...@ma...> wrote:
> 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.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
|
|
From: Florent M. <flo...@gm...> - 2025-10-22 05:30:43
|
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/
|
|
From: Zaumseil R. <RZa...@kk...> - 2025-10-22 08:20:01
|
+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
|
|
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 |
|
From: da S. P. J <pet...@fl...> - 2025-10-22 13:49:54
|
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=>
|
|
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=> > |
Thanks for helping keep SourceForge clean.
X