The "everything is a string" philosophy is at the core of the Tcl language. It is both a blessing, and, to some, a curse.
Here on this page, the general philosophy is discussed, the truth about the philosophy (that everything is NOT a string, and never has been - just all the important things...), and so forth.
Donald Porter remarked in the Tcl chatroom: More precisely, every value has a string representation. Tcl arrays are not values; they are special types of variables.
lvirden: I guess there are other things that fit into the same category as arrays - created items like procs, and in tk all sorts of widgets, etc.
aku: But most have a way to serialize them into a value, and back (array set|get, proc|info body|arg|default)
kennykb: And the ones that don't have natural serialization generally are managing external resources (channel handles are the most obvious example)
Shin The Gin: If everything was a string, then one could easily save the whole runtime environment to a file and restore it later.
[Discuss here why this philosophy makes so many things easy]
[Discuss here why this philosophy sounds like a curse word in many programmer's mouths]
When Java/Perl/Python/etc. programmers say everything's a string, they are not singing the praises of Tcl. Instead, they are criticizing the language because they believe that complex algorithms requiring data structures are not going to be possible in Tcl.
However LV would like to point out that the true philosophy of Tcl says Do all that you can in Tcl - but then, do the rest in C/assembly/whatever and create glue and handles to it for Tcl.
[Discuss here why this philosophy makes so many things hard - shimmering, etc.]
[Discuss here the idea of handles, and how the _contents_ are not strings, even while there are symbolic strings associated with the binary structure underneath of things like file descriptors, Tk's window info, etc.]
RS likes the ditty "I'm not afraid of anything, if everything is a string". In fact, the Tcl mantra often relieves fears of complexity: anything that can be brought to the prototype "string in, string out", can be nicely done in Tcl. Arabic, Korean? Of course, everything is a Unicode string! Geographic mapping? Just give me a string with the latitudes, longitudes, and whatever other data, and presto - Tclworld. Images can in many ways be rendered as strings (XBM, PNM...); one pretty intuitive way is in strimj - string image routines.
Data typing is an illusion. Everything is a sequence of bytes. Call 'em ints, floats, symbols, strings, whatever. Tcl exposes both code and data to the user as sequences of bytes (called strings). This is Tcl's choice of abstraction. And its quite a powerful choice IMHO.
-- Todd Coram
Hm, isn't it actually like that a string is a sequence of characters, and bytes (in Tcl) are just characters with the values 0 - 255? I think that's the model of binary data in Tcl. IOW bytes are not fundamental in Tcl, but characters and strings are.
-- BR
Except that characters could be Unicode instead of ASCII.
13-May-2003: Recently, Bruce Eckel in [L2 ] and Robert C. Martin in [L3 ] talk about weak typing and dynamic languages. CL thinks these two make mistakes, but hasn't time now to explain more. In any case, yes, these are good noteworthy references.
escargo 13 May 2003 - Another way that everything is a string can be an issue is where a string representation can only be an approximation of what is being represented. The main instances of this that come to mind are floating point numbers (for which there are already some existing wiki pages). There may be other examples as well.
What? There is no reason a string can't fully represent a floating point number. And Kevin Kenny has a TIP in the works to ensure that Tcl does always indeed achieve exactness in this case - Roy Terry, But really, it seems a waste of time to make fine points about "everything is a string" which is merely a programmer's cliche and doesn't begin to express the power of Tcl.
escargo 14 May 2003 - Sorry; there was a slip of the finger there. I said "floating point" and what I meant was "real".
Lars H (15 May 2003): Real numbers are beyond what is computable. The number of possible outputs from a Turing machine (and thus the set of real numbers which one can specify in any way whatsoever) is merely countable, whereas the set of all real numbers is uncountable. But this view does provide an answer to why "Everything is a string" is such a powerful idea. Many languages (most notably C) take the approach that "Everything is a number (with native machine representation) or some fixed aggregation of such numbers" , but all such representations are limited. In order to support general strings, it is necessary to venture into some scheme of dynamic memory allocation and pointers to allocated objects. The string, on the other hand, achieves the maximal generality of a Turing machine (the tape always has an obvious representation as a string) and thus if something wouldn't be representable as a string, it wouldn't be computable either.
escargo 16 May 2003 - What would it take to make Tk widgets serializable? I was thinking about xml2gui and wondering what it would take to make a widget produce an XML description of itself. Further, what would it take to have widgets that contain other widgets produce XML of themselves? This would seem to me to be one useful goal.
Another goal would be the converse, what XML would need to be used to create all the Tk widgets (and pack them the right way, etc.)? (This would be a suitable storage format for GUI Building Tools.)
17may03 jcw - There already is a serialized form of Tk, able to cope with any complexity of widget hierarchies: the Tcl script that creates them.
jmn - Yes, but is there a canonical form for it?
escargo - I am reminded of one-way hashes. You can have a function that given an input can produce a hash value that cannot be used to derive the original input. Just because I have a widget does not make it clear to me that I can derive in an algorithmic way Tk and Tcl code to recreate the widget. Perhaps this is something for the Tk 9.0 WishList, but I would certainly like to see whatever changes would be necessary to allow this (if it's practical at all).
17may03 jcw - While EIAS is indeed a wonderfully powerful and flexible abstraction, I'd like to point out that LISP'ers and Scheme'rs have a very similar set of self-contained mechanisms at their disposal, based on "everything is made up of cons cells" (it's more of a mouthful, though...). IMO, "strings" as convention to represent data in a certain way is not inherently different from other representation choices - one could even use neurons and synapses if that were practical. What EIAS does imply is "code is data" and "data can be used as code", which is why one can play so many tricks in Tcl (and in LISP).
25July05 NEM - replying to this a couple of years too late... The difference with Lisp is that cons cells aren't universal; as I understand it, some basic data types like numbers are not represented as cons cells. You could build up everything from cons cells, in a similar way to building everything from set theory, but Lisp doesn't, and so you can't treat an integer as a list. In Tcl, though, the string is the universal medium of representation, so I can treat an integer as a list (of one element).
FW: Come to think of it, what are some other typeless languages in the "everything is a string" sense - RS has already submitted and documented thoroughly the antique TRAC in Playing TRAC.
JE: MUMPS (aka "M")[L4 ] is another EIAS language. Forth and BCPL are also typeless, but there the fundamental type is a "cell" or native machine word instead of strings. (BCPL seems to be extinct, but Forth and MUMPS are still around.)
Is everything a list?
LES on April 27, 2004: I am a newbie so what do I know. But the more I use Tcl, the more I am convinced that everything is a list. And that's one of the best features in Tcl.
FW: Wrong ;)
"{", for example, is not a list. Your real point is probably that, say, numeric or other simple values can be treated as one-item lists: [lindex 123 0] == 123. Which, when you think about it, is really because of everything being a string!
Lars H: Actually,
"{"is a list (whose only element is a left brace), but
{is not a list. Although when you write them in a command you need to quote them, and "{" is one way to quote {, so
llength "{"rightfully produces the error "unmatched open brace in list". The most transparent way to quote "{" is probably
\"\{\"FW: Right, I meant "{" as in [llength "{"], not that the quotes would be part of the value.
LES: I don't think it is "transparent"...
% set x \"\{\""{"
% llength $x
1
% puts $x
"{"
Hmm... I was expecting to get { instead of "{"
Lars H: Time to reread the endekalogue? Of course the above sets x to the three character string quote, left brace, quote (set said so itself). And of course it doesn't matter that you've treated the string as a list when you later ask puts to print it; everything is a string, and merely using that string doesn't change it. You do however get
% puts [lindex $x 0]
{
% puts [lrange $x 0 end]
\{LES So right. But I still say that it is not "transparent". The brace is a special character in Tcl and will often boggle minds if it's part of that string. But now we're digressing.
Is everything a list (2)?
KJN 2004-11-04
The endekalogue does not define lists - it leaves it to commands to decide whether to interpret an argument as a list (and, implicitly, to define what is meant by a list). It appears that the list commands will automatically interpret any string as a list (unless the string has unmatched braces, see above).
I would like to express an arbitrary (nested) proper list in Tcl; but how do I distinguish
"an atom"
from
[list "an" "atom"]
It is true that I can write
{"an atom"}but it appears that list commands cannot distinguish this from
[list [list "an" "atom"]]
In short, whenever you use list commands to look at the element "an atom", it appears that they will always regard this as a list of length 2, not length 1.
Is there any way to fix this, rather than to work around it by:
(a) substituting spaces in "atomic" strings;
(b) recording the type in the expression, either only in cases where list commands would get it "wrong" (cf the 4 examples above):
[list ATOM "an atom"] [list "an" "atom"] [list [list ATOM "an atom"]] [list [list "an" "atom"]]
or always (which by warning me not to use list commands on the "atom", also saves me the job of escaping any braces inside it):
[list ATOM "an atom"] [list [list ATOM "an"] [list ATOM "atom"]] [list [list ATOM "an atom"]] [list [list [list ATOM "an"] [list ATOM "atom"]]]
(c) since "ATOM" is starting to look like a tag, give up on "simple" lists and use XML instead;
(d) give up on Tcl, and use Lisp instead
RHS 04Nov2004
There is no difference between
"an atom"
and
list "an" "atom"
I think what you're looking for is more of:
% lindex [list "an" "atom"] 0 an % lindex [list "an atom"] 0 an atom
KJN 2004-11-05
Tcl does:
% lindex [lindex [list "an"] 0] 0 an
So what I'd like is
% lindex [lindex [list "an atom"] 0] 0 an atom
but what I get is
% lindex [lindex [list "an atom"] 0] 0 an
As you say: there is no difference between
"an atom"
and
list "an" "atom"
Both are list of length 2.
RHS 05Nov2004
Ok, let me go about this another way then... Why is it you want this behavior? I think the problem is that you want you be able to say "this is a list" and "this is not a list". In Tcl, there's no such concept. You can only say "I want to treat this like a list" and "I want to treat this like some-other-thing-that-isn't-a-list".
What are you trying to do that this isn't sufficient for?
KJN I'd like to store tree-structured data, with the possibility that a leaf can be an arbitrary string. If I build up the tree using list, and then inspect it with llength, lindex and so on, I hit the problem that my intended leaf is itself treated as a list, and may have length not equal to 1. There are obvious workarounds, like the ones I've mentioned above. I wondered whether it is possible to instruct the list commands that a string such as "an atom" is to be treated as length 1, so that I could use the native Tcl commands with no workarounds. A fictitious way to do this might be
list -norecurse -- "an atom"
RS: As lists can always go via string rep and back, this hidden feature would not be stable. But how about separating the domains of "text" (any string) and "child nodes" (a list)? E.g. to model a parent node with two children,
set tree {"a parent" {{"a child" {}} {"another child" {}}KJN: yes, this is the same in spirit as my
[list [list [list ATOM "an"] [list ATOM "atom"]]]
workaround. This kind of solution is the best I can think of, because it makes maximum use of the native list commands and data structures, and avoids the need to process the leaf strings to make them both list-safe and length 1. The result
%llength "an atom" 2
surprised me, but I suppose it is a consequence of the encoding that Tcl chooses when it expresses a list as a string, plus the requirement (which you mention) of invariance when a value is converted from list to string and back again.
So, to summarise Is everything a list? (I hope I understand this now, please edit any errors)
aricb One of the fundamental properties of Tcl lists is ambiguous depth. To know how to interpret a nested list, you need some other source of information than the list structure itself. There are probably several different ways to build that information into the contents of your list.
However, one very nice alternative is the tree code in the Tcllib struct package. It's very tclish, much more convenient than rolling your own tree infrastructure, and it includes (among other features) a very nice command for traversing a tree in the order of your choice.
KJN - thanks, I'll have a look at that.
Lars H: At the end of the parsetcl page, there is a beautiful example of how a "tagged tree" can be converted to something quite different (in that case a Tcl script), by making use of the fact that every list is a command. The trick is to make sure every node, i.e., not just the leaves, is tagged and then for every tag create a proc which converts that type of subtree to the desired format. Then to convert a tree, one only has to evaluate it!
LES on August 28, 2007: An interesting thought to anyone who's just discovered Tcl: I started the Is everything a list question more than 3 years ago (see above). And see what beautiful discussion it brought up. :-) Today I feel like adding that, back then, I was probably still under the influence of Perl and PHP, languages that I used for a while before adopting Tcl. In those languages and probably others, whenever some command or function returns some text, the language will almost certainly treat it as a string. If you want to print (echo, puts etc.) it, for example, you'll have a string. Turning that string into a list (known as "array" in Perl and PHP) so that it can be used as a list requires additional steps. In Tcl, they can be treated as strings or lists almost willy-nilly. No additional steps. Whatever differences there are between a string and a list seem to be 100% irrelevant most of the time, and whether Tcl knows it or works like that just by coincidence, it still is a very practical and convenient approach. The interesting thought is that I didn't like it at first. I actually frowned upon it because it was like "too much freedom". Some mysterious feeling inside me told me it wasn't supposed to be like that. It wasn't "proper". And that's exactly how an awful lot of people feel about data types. Take types away from them and they will immediately feel robbed and outraged. But Tcl doesn't use types, everything is a string and it works beautifully. Another language may have told you that you simply cannot code without data types, but that's just someone's particular approach, not some universal truth. "Never let school interfere with your education." - Mark Twain.
MS 2004-12-04 Relevant comments moved here from How Tcl is special
Everything is a string
Wrong! Tcl has the data type, array, and in 8.5 the dictionary data type was introduced. Both of these are defiantly not strings. And, what about procs and namespaces? These are not strings either. People that say everything in Tcl is a string do not know what their talking about.
JE Actually, dictionaries are strings, just as much as lists are. But you're right: there are plenty of important entities in Tcl that are not strings -- for example, open file channels, Tk widgets, variables (both scalar and array), encodings, and interpreters. But in Tcl, all of those things are accessed by name, and the name is a string. That's why, for example, you can't pass an array to a procedure (the array is not a string), you have to pass the array name instead (the array name is a string).
MS Please refer to the precise statement and discussion at the top of this page.
If "everything is a string," then how can you tell what's an object?
escargo 23 Jul 2005 - That's what I woke up to this morning. I was thinking that Tcl lacks what I have seen called a "meta-object protocol," something that allows some object-oriented languages (like Smalltalk) to do some useful operations on objects and classes. I like Snit because of what it allows me to do to compose objects using delegation. However, if I'm operating in Tcl (or in Tk) and I have an identifier, how can I tell if its value represents an object from an object system like Snit (or any of the other object systems added onto Tcl). And if it is an object, how can I tell which object system it is an object in, so that I can guess what behavior is has (which functions it understands or implements)?
The only I can see something like this working is if there were some agreed-upon standard for names (or references) such that a classifier (say [string is object ...]) could return a yes or no answer.
Even better would be one that could tell which object system implemented the object (say [string is objectsystem ...]).
This might be possible in a system like Jim if the Jim References encoded the object system and whether something was an object.
Even without add-on object systems, it would be nice to be able to determine if there could be [string is command ...], but that in some respects defeats the purpose of unknown. (I'm still fuzzy from sleep, so maybe there is something that does this already, otherwise how would unknown get called?)
Lars H, 24 July 2005: I think the best way of pointing out how your analysis here is wrong is to point out that
indeed, it follows from everything is a string that there cannot be such a command (at least not one that doesn't just return "string" or whatever regardless of input), since nothing but the string may define the value. If you want to type-tag values, then you must include that tag in the value itself.
Put another way: Values in Tcl are what you make of them. Values don't "know"[*] that they're command names, integers, or variable names--they become whatever you decide to treat them as (or cause an error to be thrown when they cannot be interpreted the way you claimed).
A consequence of this is that one shouldn't write programs that just throws all data in a huge bowl and lets unknown (or whatever) sort it out later, one should write programs so that there at every point in the program is clear what type of data is going to be passed around. It is sometimes useful to let the type of some argument be "either an A or a B", but then one must also have sorted out whether it may happen, and if so what it means, when data comes along that is both A and B.
So what has this to do with objects, then? Everything, since whatever one uses to identify an object is just another string (even though few eyebrows are raised these days when people request magical behaviour from objects--for some reason it seems politically correct to regard objects as nobler than ordinary data). You can ask an object system whether it recognises a particular string as identifying one its objects (but this assumes the system is implemented in such a way that this is possible), and you could start an object system registry that goes around asking all known object systems whether they recognise a particular object as theirs, but that's about it, and I doubt it would be of much use outside debugging.
In a sense, the proper response to "how can you tell what's an object?" should be:
[*] Techincally, on the C level, most Tcl values kind of know from their Tcl_Obj internal representation whether they are command names, integers, variable names, etc., but it is more accurate to describe this information as if I'm a command name/integer/whatever, then I'm the name of that command/integer/whatever since this type information is shimmered away whenever the Tcl_Obj is used in a different sense.
escargo 25 Jul 2005 - This is closer to the problem that I felt I was dealing with. In a unified object system (or alternatively, where only one object system is possible), you don't have to speculate about what kind of behavior an arbitrary object might exhibit.
In Tcl (especially if you are using Snit to delegate to some arbitrary objects), you don't know (and as you pointed out, perhaps cannot know) what object behavior a particular object (for which you have a string to use as a reference) might exhibit.
If I have a string, I can use winfo exists to see if it's a Tk window.
I can use info procs to see if it is a proc.
If it were an object, then I expect that it has some behavior (otherwise what's the point of it being an object). But without knowing more about it, it's not safe to try different probes into its behavior to see what it can do. The irony is that at least some object systems for Tcl provide some kind of introspection, but I doubt that they provide it the same way, so you can't just use it to find out more about the object.
Why does this matter? - The reason I feel that it matters is that there has to be somewhere where knowledge of the type of object has to be carried around so that you can write your programs correctly. (The type in this sense being the add-on object system that implements the object.) If you can't determine the type of object from the object itself, then you have to code that information into comments or else invent some other means of doing it.
It's not that this can't be done, but it's a wish I have that the answer were within the language itself, either by implementation (e.g., you could deconstruct a reference to determine the object system) or convention (all object systems implemented an info command that all objects responded to that could, as one of the items that might be returned, respond with the name, and maybe revision level) of the implementing object system.
I realize that's not going to happen, but if enough people agreed with the need, then progress could be made in that direction.
NEM 25July05: This all boils down to fundamental philosophical beliefs about the nature of values and types. What really marks Tcl out from most other languages, and what is at the heart of this debate is not that strings are such wonderful things that they should be used for everything, but rather a recognition that the notion of a "type" of a value is extrinsic to the value itself. In other words, a type is an indication of some interpretation of a value. Any representation of a value can have multiple different interpretations, and so to talk of the type of a value without reference to the particular system doing the interpretation is difficult. Conversely, any abstract type can have multiple possible representations (the key idea of abstraction/encapsulation). So, the connection between values and types is a many-to-many connection. Most languages assume a 1-to-many connection, so each value has a single type which is associated with it by the language, with less categorisation left up to individual commands/functions (although it is not true to say that no choice is left; every function performs an interpretation of its arguments to some degree). Tcl, however, is different in that it performs almost no interpretation of the values it is passed. It does basic tokenization and grouping, but leaves values as they are found: as strings. The only further bit of interpretation that Tcl does is to treat the first word of each line (talking loosely) as the name of a command. (Well, there is also variable substitution and other items in Tcl.n, but we'll ignore those for now). It is then the individual commands which take care of any further interpretation. You can think of this as a form of extreme lazy evaluation: even parsing is left to the last possible moment.
So, what are the trade-offs? On the negative side, the fact that Tcl does less interpretation for you means that it makes fewer guarantees (e.g., it's hard to do garbage collection of references if you can't guarantee that X is a reference and Y isn't). Another difficulty, is that it is possible to break abstractions in Tcl: you can always drop down to the level of strings and manipulate the representation of a value, rather than use any higher-level interface. I actually think this is one of Tcl's strengths, but it is a longer argument. You can also get around this by using opaque handles, which hide the representation behind a layer of indirection, that may or may not be introspectable. On the plus side, the fact that Tcl has an ultimate fear of commitment, means that commands have more free reign in deciding how they will interpret the values. This, I suggest, is the heart of what makes Tcl a good glue language: by not committing to a single interpretation of a value it allows multiple components to make their own, possibly conflicting, interpretations. (As an aside, an interesting parallel can be drawn here with Daniel Dennett's Multiple Drafts theory of cognition/consciousness). Another way to look at this is to say that by providing a common representation medium you reduce the number of explicit conversions that have to be done. If you have N distinct types, then in order to convert between them you potentially need N!/(N-2)! different conversion functions (i.e. N 2-way permutations, e.g. int2double, double2int, int2string, string2int, etc). If you have a common representational medium, then you can use that as an intermediate, thus reducing the number of conversion functions needed to just 2(N-1), and just two functions are needed for each type: toString and fromString (the string type itself obviously doesn't need these).
Can we combine the benefits of both approaches? I think we can. TOOT was about doing just this, and Interpreting TOOT has my earlier thoughts on the subject. I've been thinking about this some more since, and will hopefully soon have time to write some more code and an essay detailing my further thoughts. For now, I will point at Monadic TOOT, which contains some clues to a possible way forward. Those who know about monads will know that they are useful for confining effects and enforcing abstraction boundaries. I think we can use the same techniques in Tcl to create packets in which abstractions can be enforced and guarantees can be made, if needed. The other side of this process is partial evaluation, a TOOT bundle of
type: value
can be partially evaluated (or partially applied), to yield a new function specialised for that interpretation of that value. This can be optimised and can enforce a type abstraction.
Lars H: Well put. The part about late "commitment" puts a name on something I think is very important in understanding the strengths of Tcl. I'll see if I can find a good place to put this idea for easy access.
SYStems, 23 Jul 2005: Those are not very complete thoughts, but. I think to really answer and understand the idiom everything is a string, we need to identify the context, or perspective.
A Tcl script is a series, a sequence of statements, each statement receive input
perform action on this input and then
Every statement input and/or output is a string, only side effects (and maybe input events) can be NOT A STRING, but all input and output must have a string representation.
Each input and ouput, can have a different in-memory representation, or on disk representation. But inside a script it must have a string, or I prefer to say, textual representation.
Since everything written in a Tcl script, is textual. A script can be the input of a Tcl command, for example control structure commands.
Every input, must have an inline textual representation, this is why an command must have a textual ouput, so that when its substituted it produces a string, the only thing that is good as an inline input.
All input and output must have inline textual representation (this is the part I an hesistant about, I am not really sure this is correct, I am using the word inline loosely here I propably mean infile!!)
set is the command used to manage a Tcl script memory, all set variables must have a string value.
This may sound weird, but I write this hoping that Tcl doesn't lose its primary principles. For example, I see many people talking about Tcl variables, Tcl doesn't have variables, set a command that have a Tcl interface, give a Tcl script the notion of variables by associating a name with a string value.
Depending on the value-string-representation, set will store it differently in-memory. set not Tcl.
set for example, doesn't store the variables on disk. A good Tcl'er might create a command that give a Tcl script the notion of persistant data, data stored on disk!
Tcl help set thought by recognizing the syntax $name, and treat that as [set name]
Anyway, back to the fact that set can only associate a name with a string. set is used to store another tcl command's output, and pass it later as an input.
[ LV Uh - maybe that is how you _want_ it to work. But since I can say
set abc "123"
then set doesn't just store another tcl command's output...]
So we can say that everything inline- a tcl script, anything that can be passed around, a tcl script memory, a tcl script internal environment, must be a string. Or in other words, we can say, that Tcl introduces a new in-tcl context, where everything must have a textual representation.
Anything outside a Tcl script, outside the in-tcl context, for example, a command side effect, or an external environment, can be not a string.