Inline return values
in [TCL]
|
From: slebetman on 1 Jul 2008 21:25 On Jul 1, 7:44 pm, Kaitzschu <kaitzs...(a)kaitzschu.cjb.net.nospam.plz.invalid> wrote: > On Tue, 1 Jul 2008, dave.joub...(a)googlemail.com wrote: > > On Jun 30, 12:35 pm, Kaitzschu > >> set tl [lrange [split [read $in] \n end-[incr n -1] end] > > > As an aside, I found myself shocked at the thought that one could use > > incr that way! > > <snip> > > There has been some tangential discussion using "inline return values" on > tclcore mailing list regarding [chan pipe], but I guess this doesn't > really apply since using a "mutator" command this way is most likely going > to result in an error, as you point out with your scenario. > > But I like it! Even if it is going to put a nail to my foot sometimes :) > Ah yes, for "casual" programming tasks I also like (ab)using return values of commands. I especially like that [set] always returns a value. My favourite (ab)use is the "slurp" one-liner: set data [read [set f [open $filename]]][close $f] Of course, in production code it's not a good idea to do this.
From: Kaitzschu on 2 Jul 2008 07:43 On Tue, 1 Jul 2008, slebetman(a)yahoo.com wrote: > On Jul 1, 7:44 pm, Kaitzschu > <kaitzs...(a)kaitzschu.cjb.net.nospam.plz.invalid> wrote: >> On Tue, 1 Jul 2008, dave.joub...(a)googlemail.com wrote: >>> On Jun 30, 12:35 pm, Kaitzschu >>>> set tl [lrange [split [read $in] \n end-[incr n -1] end] >> >>> As an aside, I found myself shocked at the thought that one could use >>> incr that way! >> >> <snip> >> >> There has been some tangential discussion using "inline return values" >> on tclcore mailing list regarding [chan pipe], but I guess this doesn't >> really apply since using a "mutator" command this way is most likely >> going to result in an error, as you point out with your scenario. >> >> But I like it! Even if it is going to put a nail to my foot sometimes :) > > Ah yes, for "casual" programming tasks I also like (ab)using return > values of commands. I especially like that [set] always returns a value. > My favourite (ab)use is the "slurp" one-liner: > > set data [read [set f [open $filename]]][close $f] That is still very readable and only thing that can confuse reader is if (s)he doesn't know that [close] returns an empty string (which is phased out). But once we have a -unique -sorted $list that needs to be added an $item while ${exclude}ing another and still kept -unique -sorted in case $item already was there, then we have one ugly one-liner: [code] set list [lreplace [set list [lsort -unique [lappend list $item]]] [set ind [lsearch -sorted $list $exclude]] $ind] [/code] ...which mutates list once, twice, three times (plus $ind is calculated in the mist). And does different things to each cycle (which, obviously, is needed, since otherwise there is no need for mutating the value, return value could be used directly; true, list is [lappend]ed for nothing, but [linsert] is uglier). [code] lappend list $item set list [lsort -unique $list] set ind [lsearch -sorted $list $exclude] set list [lreplace $list $ind $ind] # lreplace will bail out when $ind isn't in range (-1 = not found) # woohoo, 4-fold increase in LOC! plus vague documentation! [/code] > Of course, in production code it's not a good idea to do this. So _that_ must be the reason I'm not being considered a productive member of society :P -- -Kaitzschu set s TCL\ ;wh 1 {pu [set s [st ra $s 1 3][st in $s 0]]\033\[1A;af 99} "Good thing programmers don't build bridges [the same way as Kaitzschu writes code]." --John Kelly in comp.lang.tcl
|
Pages: 1 Prev: Funny difference between aliases and args Next: Extensive Tcl/Tk Library for Sale (21 volumes) |