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

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

Hi Donal, Hi all :

Is it not to much in matter of syntax change ?

Will your ask everybody to change all their expr in all their script to 
adopt the new Tcl Version ? The adoption of this new version will be 
very long, if it ever happens. It may even finish by disgusting people 
of Tcl itself.

I think it's better to respect the actual Tcl C code, to say : Some 
choices have been done, that can't be change anymore. This is the way 
Tcl was build : let's see where it can go this way.

Personnally, I'm not disturbed by the '$' sign, I'm very used to 
it. When I see a '$' in Tcl, I think immediately : variable.

That's why I'm not fond of the $((...)) syntax.

In Tcl, the '$' sign is the mark of variable, whereas the '[ ... ]' is 
the mark of command. It is an historical choice. It can be respected.

To properly improve the expression handling, but without breaking every 
expression, I think there is 5 things that can be done :

  * 1° A shorthand syntax. Ex : [( ... )]
  * 2° An instruction separator ";"
  * 3° A native list handling via coma separator. Ex : [( $x, $y, $z )]
    will return [list $x $y $z]
  * 4° Support for {*}prefix, but adapted for expr, with coma separator,
      o ex : [expr {{*}[list $x $y $z] }] means [expr {$x, $y, $z}]
  * 5° An assignement operator :
      o As the left value is a variable, and as a variable in Tcl is
        mark by a '$', let's mark the left value... with a '$'
          + This way, there won't be any ambiguity between command and
            array, so a lot less of headaches !
      o make it able to assign multiple value once.

Then, we can write things like these :

proc Coords {R theta} {
     return [(
          $x = $R*cos($theta);
          $y = $R*sin($theta);
          $x,$y )]
}

(86 chars) instead of (95 chars):

proc Coord {R theta} {
     set x [expr {$R*cos($theta)}]
     set y [expr {$R*sin($theta)}]
     return [list $x $y]
}

and

proc Cross_Product {v1 v2} {
     return [(
          $x, $y, $z = {*}$v1;
          $a, $b, $c = {*}$v2;
          $y*$c-$z*$b, $z*$a-$x*$c, $x*$b-$y*$a )]
}

(132 chars) Instead of (175 chars):

proc Cross_Product {v1 v2} {
     lassign {x y z} $v1
     lassign {a b c} $v2
     set X [expr {$y*$c - $z*$b}]
     set Y [expr {$z*$a - $x*$c}]
     set Z [expr {$x*$b - $y*$a}]
     return [list $X $Y $Z]
}

Of course, there is a lot of dollars : it is suboptimal on this point of 
view. But I don't think that will not disturb too much a Tcl coder that 
is use to associate it with variable.

Moreover, every [expr { ... }] you wrote since you began Tcl will still 
remain correct.

Regards,

Florent

Le 02/11/2025 à 10:04, Donal Fellows a écrit :
> Doing the job properly would definitely involve changing the 
> expression parser, with my suggested fix being to turn all bare words 
> not otherwise recognised as constants or in positions that look like 
> function calls (it's a parser with some lookahead) into simple 
> variable reads (NB: C resolves such ambiguities within itself 
> differently, but that's one of the nastiest parts of the language). We 
> would need to retain $ support for resolving ambiguity (e.g., array 
> reads vs function calls; you can't safely inspect the interpreter to 
> resolve it at the time of compiling the expression due to traces and 
> unknown handlers) as well as compatibility, but that's doable as it is 
> a change only in cases that are currently errors.
>
> Adding assignment is quite a bit trickier, as that needs a new major 
> syntax class to describe the left side of the assignment. I suggest 
> omitting that from consideration at this stage.
>
> Donal.
>
> -------- Original message --------
> From: Colin Macleod via Tcl-Core <tcl...@li...>
> Date: 02/11/2025 08:13 (GMT+00:00)
> To: Pietro Cerutti <ga...@ga...>
> Cc: tcl...@li..., av...@lo...
> Subject: Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready 
> for Sponsorship
>
> Indeed, this toy implementation doesn't handle that:
>
>     % = sin (12)
>     can't read "sin": no such variable
>
> I'm not sure that's serious, but it could be fixed in a C implementation.
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core