|
From: Florent M. <flo...@gm...> - 2025-10-23 14:45:22
|
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 |