From: ZB on
It is quite often, when we have to write something like this, for example:

set chosenButton [lindex [dict get [info frame -2] cmd] 0]

Such nesting can even go further. A workaround can be e.g. use of temporary
variables, which isn't convenient, and makes code more verbose.

Having in mind introduction in 8.5 i.a. a practical new {*} operator,
I would to ask: what if we had pair of operators, like this:

"->" which means: "transfer result/value to"
"<-" "insert here" (in case of need to point, where)

The example verse could be then rewritten in a way:

[info frame -2]->[dict get <- cmd]->[lindex <- 0]->chosenButton

Isn't it more readable?

Another example - setting multiple variables with the same value:

1->a->b->c->d

What do you think? Would it be technically possible to implement?
--
Zbigniew
From: Torsten Berg on
Hi,

> It is quite often, when we have to write something like this, for example:
>
>   set chosenButton [lindex [dict get [info frame -2] cmd] 0]

True.

> Such nesting can even go further. A workaround can be e.g. use of temporary
> variables, which isn't convenient, and makes code more verbose.
>
> Having in mind introduction in 8.5 i.a. a practical new {*} operator,
> I would to ask: what if we had pair of operators, like this:
>
> "->" which means: "transfer result/value to"
> "<-"              "insert here" (in case of need to point, where)
>
> The example verse could be then rewritten in a way:
>
>   [info frame -2]->[dict get <- cmd]->[lindex <- 0]->chosenButton
>
> Isn't it more readable?
>
> Another example - setting multiple variables with the same value:
>
>   1->a->b->c->d
>
> What do you think? Would it be technically possible to implement?

Hm, interesting but difficult.

How would you make sure, that the right order of arguments for the Tcl
commands is preserved? Semantically, I don't see the true difference
between <- and ->. After all, it is just a transfer of a value/result
(everything is a string) to some command or variable. It allows only
to transfer 2 "things", one from left, one from right, but what about
commands that take 3 or more arguments? Or even options?

Torsten

From: ZB on
Dnia 29.05.2010 Torsten Berg <berg(a)typoscriptics.de> napisa�/a:

> How would you make sure, that the right order of arguments for the Tcl
> commands is preserved? Semantically, I don't see the true difference
> between <- and ->. After all, it is just a transfer of a value/result
> (everything is a string) to some command or variable. It allows only
> to transfer 2 "things", one from left, one from right,

No, don't be misleaded by the shape ("arrows"); the "left arrow" means - as
I wrote - just "insert the transferred value exactly here" (call it
"inject", if you like ;). Replace it in your mind with big "X", for example.

> but what about commands that take 3 or more arguments? Or even options?

Read my example: my idea was to replace not-so-well readable nested
commands; I'm not proposing any kind of "panaceum".

I guess, you mean something like this:

set x [commD [commA [commB x -parB] [commC y z -parC] v w -parA] t u]

Still you can simplify this in proposed way adding one temporary variable:

set tmpB [commB x -parB]
[commC y z -parC]->[commA $tmpB <- v w -parA]->[commD <- t u]->x
unset tmpB

Doesn't it look much more comprehensive and tidy, that the very first version?
--
Zbigniew
From: ZB on
Well, almost. You got the point - but I'm afraid, having it done in "pure
TCL" - therefore relying on "eval" - won't make it universal (usable with
*every* piece of code). Let's take a look (added 3 puts-es to keep the track,
what's going on inside):

#v+
set a ""
set _val ""
set _stack [list]
proc evalThis args {
global a _val _stack
foreach a $args {
switch -glob $a {
-> { lappend _stack $_val ; puts |1|$a| }
*\ * { regsub -all {<-} $a {[pop _stack]} a ; puts |2|$a| ; set _val [uplevel 1 {eval $a}] }
* { puts |3|$a| ; uplevel 1 {set $a [pop _stack]} }
}
}
}

proc pop vv {
upvar $vv v
set ret [lindex $v end]
set v [lrange $v 0 end-1]
return $ret
}
#v-

First attempt:

#v+
% source evalthis.tcl
% evalThis {expr {2+2}} -> y
|2|expr {2+2}|
|1|->|
|3|y|
% puts $y
4
%
#v-

So far - so good. So let's try a little longer example:

#v+
% evalThis {expr {2+2}} -> {expr {<- + 3}} -> y
|2|expr {2+2}|
|1|->|
|2|expr {[pop _stack] + 3}|
|1|->|
|3|y|
% puts $y
7
%
#v-

Still OK, right? So have a look at this one:

#v+
% evalThis {expr {2+2}} -> {set abc {expr {<- + 3}}} -> y
|2|expr {2+2}|
|1|->|
|2|set abc {expr {[pop _stack] + 3}}|
|1|->|
|3|y|
% puts $abc
expr {[pop _stack] + 3}
% puts $y
expr {[pop _stack] + 3}
%
#v-

....and that's I was afraid of. Pay attention: of course, I realize, that the
above example can be rewritten in the way:

#v+
% evalThis {expr {2+2}} -> {expr {<- + 3}} -> abc -> y
|2|expr {2+2}|
|1|->|
|2|expr {[pop _stack] + 3}|
|1|->|
|3|abc|
|1|->|
|3|y|
% puts $abc
7
% puts $y
7
%
#v-

....but this is just a specific example; in "real life" *every* piece of code
should be handled correctly (I mean: according to assumptions, how it is
supposed to be working). The example in its former shape is a line of
lexically correct code, which won't be handled properly.

Well, maybe it can be improved using a little recursion(?) - a bit late today
now ;), but I'll take a look tomorrow. Thanks, anyway: in many situations
even such solution, used with a little care, still can be useful.
--
Zbigniew
From: Donal K. Fellows on
On 30 May, 01:41, ZB <zbTHIS...(a)ispid.THIS-NOcom.pl> wrote:
> ...but this is just a specific example; in "real life" *every* piece of code
> should be handled correctly (I mean: according to assumptions, how it is
> supposed to be working). The example in its former shape is a line of
> lexically correct code, which won't be handled properly.

There are ways to lift such operations to working over entire
procedures or scripts (e.g., overriding [proc] and [source]). Your big
issue is going to be dealing with existing code which uses -> and <-
for other purposes. For example, I use -> in [regexp] quite a bit as
the variable name for the whole-string match where I only really want
the substring matches...

Donal.