Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship

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

Le 23/10/2025 à 13:11, Donal Fellows a écrit :
> ​
>
> 	
> Conclusion : There is no real choice
>
> ​
> That's an incorrect conclusion. At least one of the priors you use in 
> reaching it is invalid.
> The core of the proposal is that the sequence *$(* start a 
> /new/ syntax category (with what follows being an expression to the 
> point where there's a /matching /parenthesis using an appropriate 
> recursive matching algorithm, with a similar model to how command 
> substitutions work). This new syntactic entity will be called (almost 
> certainly) an /expression substitution/. That it starts with *$* is 
> good; existing code that inserts backslashes before dollar signs to 
> make things *subst*-safe will not be surprised; normally we'd 
> recommend such approaches instead now switch to using *regsub 
> -command*, due to the way *subst *works, but that's a longer-term 
> change-over.
>
> That the C code inside the Tcl parsing engine will need to change to 
> accommodate a new syntax category isn't a deep insight. Of course it 
> will need to change. Such change is what is being proposed!

But there is change, and change.

- in matter of quantity : Which syntax will lead to the minimal change 
in the c-code ?

- in matter of quality : Which syntax will give the cleaner c-code for 
the reader ?


About this proposal « $(...) »

in matter of quality, the fact that the expression substitution is 
detected in a procedure whose name is Tcl_ParseVarname is highly 
illogical (not clean)

in matter of quantity, the fact that :

  - subst is defeat (confusion of variable and math expression) will 
imply corrections, whereas it's just the consequence of the previous 
conception illogicality (more code)

  - the impossibility of this new syntax to nest will imply corrections 
in Parse_Expr (more code)

  - the necessity to track memlink will imply more changed too (more code)


About the proposal « [( ... )] »

In matter of quality, the fact that a math expression is a command is 
logical (more clean)

In matter of quantity :

  - subst won't be defeat : no command, no expression : no change 
needed, but new feature possible of course (less code)

  - The syntax may easily nest, since it will fall in the SCRIPT case of 
the /Parse_Expr/ procedure, that will call /Tcl_ParseCommand/ then 
/Parse_Token/ (less code)

> Right now, the real discussion is what the sequence of literal 
> characters in a Tcl script to introduce the new syntax should be. The 
> options in play are:
>
> 1.
>     Do nothing. Stick with *[expr {*expression...*}]*. This option is
>     /always open/ to us.
> 2.
>     Use *$(*expression...*)*
> 3.
>     Use *$((*expression...*))*
> 4.
>     Use *[={*expression...*}]*
> 5.
>     Use *[=* expression...*]*
> 6.
>     Use *[(*expression...*)]*
> 7.
>     Use something else (I've probably missed an option or two from
>     this painting of the bikeshed)
>
The better way be should to implement each of these proposals and 
compare it in quantity as well as in quality.

I really would like to implement the « [( ... )] » variant, sadly, I 
have neither the time, neither the infrastructure, neither the 
competence to do so.

I am absolutely sure the result will be, finally, simpler than the other 
alternatives (since an expression is a kind of command...)

Is someone interesting to get a try ?

Florent