Menu
▾
▴
Re: [TCLCORE] Fwd: TIP 672 Implementation Complete - Ready for Sponsorship
|
From: Colin M. <col...@ya...> - 2025-11-02 14:21:14
|
Hi Florent,
I don't think anyone is suggesting removing the existing `expr` or
making an incompatible change to it, just adding another form of expression.
Colin.
On 02/11/2025 14:11, Florent Merlet wrote:
>
> 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
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core |
