''This page split out from [Tcl 9.0 WishList]''
----
[MSW] @ 18 Mar 2003 '''multiple assignments via [set]'''

include something simliar into the core for [set]

 rename set theset
 proc set {args} {
  switch [llength $args] {
    0 { return -code error {wrong # args: should be set varname ?newvalue? ?varname ?newvalue?? ...}}
    1 { return [uplevel "theset [lindex $args 0]"] }
    2 { return [uplevel "theset [lindex $args 0] [lindex $args 1]"] }
    default { 
      uplevel "theset [lindex $args 0] [lindex $args 1]"    
      return [uplevel "set [lrange $args 2 end]"]
    }
  }
 }

''i.e.'' allow set to set multiple variables at once, where the last
one potentially gets no newvalue. The value of the last ''varname''
is returned. I've really seen enough of
 foreach {a b c} {1 2 3} {}
don't you think 
 set a 1 b 2 c 3
looks much nicer ? :)

[RS] Agreed - and it matches the way the [variable] command can be called. Just a little nit: it seems to become an idiom to rename original Tcl commands into the tcl namespace, so I'd write (testing, so I don't lose the original on repeated sourcing)
 if {[info command tcl::set] == ""} {rename set tcl::set}

[MSW] Good point - I've added it like this as an example to the [set] page.

[DKF] - I favour adding [TclX]'s [lassign] command.  It's well known already, and it doesn't tinker with the behaviour of a very basic core command.  [TIP]s 57[http://purl.org/tcl/tip/57] and 58[http://purl.org/tcl/tip/58] cover this sort of area as well.

[MSW] I disagree. [lassign]'s syntax is no bit better than abusing foreach, and that's how it looks like. Having a TIP there (#58 looks fine) is a good reason that this entry is not needed. And I don't think that leaving a core command at a crappy state is a good argument against enhancements. [lassign] and [variable]'s semantics are different. It would be better that if whatever you used for multiple assignments (and I do favour [set], for no incompatibility to its current use will arise!) had the same conventions as variable has, or changing variable to have the same convention lassign has - and breaking tons of scripts.

[RS]: I think the [foreach]...[break] idiom is no abuse. [foreach] has two functionalities:
   * assign values from one or more lists to one or more variables;
   * iterate with these variables over a code body.
Both functionalities can be used by themselves, and I think these are no abuses:
 foreach {x y z} $threeValues break
 foreach _ _ {#some code that runs once and may be left with [break]}

[MSW] I think it's an abuse because I'd prefer to not have foreachs iteration variables in the calling scope, and thus I treat foreach as if it didn't clobber its calling environment. But that's personal preference. Both the uses you cited as 'valid' uses of foreach are nice obfuscators imho...

----
[FW]: Optimize the idiom
  foreach {a b} {1 2} break
to be byte-compiled automatically into a series of ''set'' operations, making it no longer a major slow-down for small utility procedures that are run repeatedly.

[jcw] - How about extending "set" a teeny bit?  Perhaps like this:
   % set a b c {1 2 3}
   1 2 3
   % set a
   1
   % set b
   2
   % set c
   3
   %
[FW]: I was gonna suggest that, but that's a more dramatic change.  In an ideal world, both would happen, but Tcl gets changed extremely slowly, so it'd be idealistic to suggest both at once ;)

[rmax]: I think both changes would even be allowed in a minor release, as the foreach optimization doesn't change behaviour at all, and the set extension only makes a backwards compatible change.

[DKF]: There's a currently Draft [TIP] on extending the [set] command, and it is really unpopular with the [TCT].  We're kind-of hoping the author will withdraw the TIP sometime so we don't have to be mean and vote the suggestion down.  FWIW, the consensus seems to be that the set command is inviolate, even across major versions.

[DKF]: The TIP in question is #58[http://purl.org/tcl/tip/58] and it looks like it will be rejected outright (as I write this, the vote is in progress but there have been many votes against and none for.)

[DKF]: Yep.  Utter rejection.  Anyone wanting to modify [set] had better not rely on core mods to do it!

[FW]: Does the TCT have an opinion on the foreach mod idea?  :)

[DKF]: Try TIP #57[http://purl.org/tcl/tip/57] instead, though perhaps recognizing the [foreach]-as-multi-[set] idiom and getting smart with it may be done at some point too.

[FW]: The thing is, the current idiom is just as understandable, already in use, and doesn't add a new command just for sugar.

[DKF]: If we put [TclX]'s [lassign] in the core, I think you'll find that that does rather more than the foreach idiom.  :^)
----
[Category Suggestions]