A transparent value, in contrast to a handle, contains enough information to generate the corresponding internal representation.
NEM Transparent values in Tcl, are those which directly represent the value, as opposed to handle values which are more like pointers or references in other languages. Transparent values include things like lists, dicts (in 8.5) and strings. Transparent values are first-class in that they can be passed directly to commands, and returned from commands. Handles are first-class, but the things that they are handles for (what is being pointed to) are not first-class, as they can only be passed around via a handle. For instance, commands are a handle value - you pass around the name of the command, rather than the command itself (Tcl uses a hashtable or similar to map the name to the actual command internally). On the particular issue of commands, see TIPs 187, 194, and 196 which all try to introduce first-class transparent commands into Tcl.
Lars H: An advice to people who are new to Tcl is to try to do all data structures "transparent" in this sense. Tcl can do a lot more with transparent values than most other languages can, which means experience from other languages on how to implement things may be irrelevant for Tcl.
The main thing that can prevent something from being a transparent value is that it doesn't support the copy-on-modification semantics: that data isn't modified in place, but that rather a modified copy of the data is created. A typical example of something that doesn't have copy-on-modification semantics is a text document window; when you change a document by typing some additional text, you want the change to be in the same window, not have a new window created with the changed version of the document. Therefore windows are referenced using handles (the so-called "path name" of the window) in Tk. Similarly opened files (i.e., channels) have to be handles. Neither complexity nor size of data are good reasons for making values non-transparent, however.
escargo 2004-05-21: Does this make transparent effectively the same as immutable?
NEM: Yes. All Tcl values are immutable. Under the hood, things are a bit less black and white, as if a value is only referenced in one place then you can alter it directly, whereas if the value is shared, then you must copy it before modifying it (copy-on-write). Tcl variables however, are mutable (you can change the value they contain), unless you prevent that with traces.
jcw: I'm going to be a bit pesky and pedantic on this use of words... I find the phrases "transparent value" and "(im)mutable value" a bit confusing. Have never seen such use of the word transparent before. As for values: they are not mutable or immutable, they are values. The number "123" has no mutability aspect, it "is" the number 123 (or rather the text representation for the abstract number). Same for other values. You cannot change a "1" to a "2", you can put a "1" or a "2" in a variable. The thing that mutates is the container for the value (memory cell, variable, array, vector, list, whatever). That's why for example Python talks about the distinction (which is very essential there) between mutable and immutable types of objects.
Tcl is all about values, and not allowing anything to be mutable other than variables and arrays (and namespaces, and procs, and aliases, one could argue - i.e. state which can be altered). If you want to alter something to which something else refers by name, it has to be one of those things. There's no way (conceptually) to alter a list in Tcl, you end up with a new one (this is done quite efficiently). You can of course put that altered list back in the same variable the original came from (commands such as "lappend" will do just that for you).
I think that what the name of this page refers to, is a description of just that: everything that gets passed around is a string, everything is a value. I guess one could say the transparency is that "things are themselves" in a vague manner of speaking. Whereas mutability requires the name of a var (array, namespace, proc, aliase) to be passed around, not the values themselves.
To make the story complete: names are strings too, therefore values. Cool, so they too can be passed around!
NEM: I was using transparent to refer to an actual value, where the complete state is represented in the string rep, as opposed to handles where the value is hidden behind a level of indirection. I agree that talking about mutable vs immutable for values is slightly confusing, because real values are always immutable. However, I don't think there's any problem with explicitly spelling that out. You're right though, that Tcl is about values, or at least, should be. By the way, if I remember correctly, I first saw the terminology "transparent" and "handle" in the Feather paper.
Yes, names/handles are strings too - otherwise they wouldn't be visible at the Tcl level, where everything is a string. But, the actual state referred to by the handle need not be visible at the Tcl level (e.g. channels) - thus they are not "transparent".