Purpose: to discuss the various types of variables Tcl supports

----

Tcl is often said to be a 'strings only' language.  However, a string is not always 'just a string', strings only doesn't imply scalars, etc.

In this section, I hope that contributors will add information about the various kinds of data that Tcl can manage, as well as discuss the kinds of things Tcl variables can represent.


   * Tcl objects
   * scalar strings - ASCII vs UNICODE
   * string arrays (hash tables)

   * list - regular and keyed
   * handles (values returned from open, etc)
   * widgets (values returned from Tk commands)
   * Byte Codes (compiled script code)

----

'''Tcl Objects'''

Tcl stores values internally as "objects."  Every object has a string representation, but it may also have another, internal, representation.  Tcl will automatically translate the object into whatever format is needed, but it will perform the translations only as-needed.

For example, if you set a variable to a value like this:

     set a 2

Tcl will create a variable object named ''a'' and assign it a string value with a single character (not counting a null terminator) "2".  
If you use the variable ''a'' in a context that requires an integer, like:

     incr a

then Tcl will translate the string "2" into an integer.  The ''incr''
command will change the integer value, so the string value will be invalidated.  Tcl will continue to use the variable ''a'' as an 
integer until it is needed as a string.  If you print out the
value of ''a'', then Tcl will create the appropriate string representation.

This "dual representation" of Tcl Objects makes it possible to implement many efficient data structures.  Tcl has object representations for booleans, integers, floating point numbers, lists and byte codes.

----

'''Scalar Strings'''

----

'''String Arrays'''

----

'''Lists'''

----

'''Handles'''

----

'''Widgets'''

----

'''Byte Codes'''

The most significant performance enhancement in Tcl 8.0 is the addition of a byte-code compiler.  The compiler will automatically translate a script into byte codes the first time it is evaluated.  (This is called "just in time" or "on the fly" compilation, if you are looking for the buzz words.)  The byte codes are then executed by a virtual machine.

Subsequent executions of the script (or loop) directly execute the byte codes, instead of re-parsing the script.  If you change the script (e.g., dynamic script generation), then it will have to be recompiled.  Otherwise the byte codes are saved and re-used.