Tcl Source Code

This patch adds a new command called [lconvert] 
and a new Tcl_ObjType, "plist".  A "plist" 
or "parameter list" is identical to a list with the 
following LARGE exception:  when a "plist" is used 
in ANY command, it is expanded.  The syntax of 
[lconvert] is as follows:

lconvert varName ?type?

where "varName" is the name of a pre-existing LIST 
or PLIST variable to convert.

where "type" is optional and if specified, must 
be "list" or "plist".  

if "type" is omitted, the current type of the list 
variable is returned, otherwise, the newly converted 
list is returned.

an error is returned if you try to convert a non-list, 
a non-existant variable, or if you try to convert a 
list to the type it currently is.

WARNING: This patch MAY VERY WELL break a lot 
of things.  It is meant only as a proof-of-concept.  
If and when all the quirks are worked out, a TIP will 
be forthcoming.

---------------------------------------

For example:

% set x [list 1 2 3 4]
1 2 3 4
% lconvert x plist
1 2 3 4
% file join $x
1/2/3/4

Normally, [file join] takes a variable number of 
arguments and joins them together with a path 
separator.  In this case, we only passed one real 
argument (a "plist") and it was expanded 
automatically to four "real arguments".  This can 
also be accomplished with [eval], although that is 
not as safe:

% set x [list 1 2 3 4]
1 2 3 4
% eval file join $x
1/2/3/4

For more information, please see the Wiki page at:

http://wiki.tcl.tk/lconvert

--
JJM

Logged In: YES 
user_id=79902

This approach to the expansion problem was rejected during
KBK's poll on the topic on tcl-core

Logged In: YES 
user_id=79902

Am I right in saying that this makes lists be expanded by
the [] syntax when substituted?  If so, has the author
considered what happens when the retagging of the value is
performed in other ways, such as when it is the result of a
script?

  proc foo {} {
     set list [getsomelistofstuff]
     puts "list is $list"
     lconvert $list
  }
  set bar [foo]  ;# Blows up unexpectedly!

If the above holds, then consider what happens when foo is
invoked from another interpreter (e.g. if it is in a safe
interpreter and it is invoked from the master.)  If it does
*not* hold, so that the magic only ever happens for
[lconvert ...], then you've really got a very tricky new
syntax construct.

I don't like either.  Though the competing {expand}...
syntax sucks, it sucks less when it comes to considering
these other modes of failure.

Logged In: YES 
user_id=148712

This patch introduces new syntax, [lexpand] is not a tcl
command in the previous sense (see wiki page). Resolution
deferred until the syntax discussion is resolved in other
forums.

File Added - 42089: lconvert.diff