"Data is not abstracted from the language". This phrase from [About Tcl and popularity] has been echoing on my mind. I sort of understand what it means. But only so much. I can't say I understand it because I still can't see the possibilities it creates. More explanation, examples and lucubrations welcomed. ---- [RS]: The language manifests itself in scripts, which are [string]s. It is brought to life in commands, which are [list]s (which are a view on strings). In data, [everything is a string], and many strings can be [eval]ed if they're in the (current) language. Every proc can be reconstructed to be a string with [info args], [info default], [info body]. In short: Code is data. [Data is code]. Everything is possible :) [LES]: I understand that. But that still is as far as I could go before I asked my question. I still don't see what ocean of possibilities that wondrous trait could open to me. A little but very practical example, perhaps? Anyone? [LV]: Think of it this way. When someone programs in a language where data is separate from the language, it becomes more difficult to do things like dynamically change the application. If I were writing C code, and I wanted the user to be able to change the application they were running for some reason, then I'd have to have them provide me some data, then generate or modify one or more C code files (or files to be included by the C code), then exec a compiler, and, when that worked, exec the new binary overtop the binary currently running in memory. I'd have to be careful on some systems that the modified binary didn't replace the running one on the disk, because on some systems that would crash the application. Now, take a look at a dynamic language like Tcl. In Tcl, the user can provide input, or Tcl can generate (even randomly), code that can be either executed immediately, or code that can be written to disk and then [source]d into the current interpreter, or modify the current application and exec it just like we did in C. [LES]: Thanks, but it's still too abstract. An example would make a big difference. [RS]: OK, a tiny example (from [entry]) - "Programmable calculator, with GUI, in two lines of code": pack [entry .e -textvar e -width 50] bind .e {catch {expr [string map {/ *1.0/} $e]} res; append e " = $res"} ;# RS What happens in the second line is that user input from the entry is rewritten to force double division, and then evaluated by [expr]. Arithmetics are normally in the centre of high-syntax languages like Fortran/C/Java; for us it's just a string that may happen to parse well at runtime (otherwise, the error message is displayed in the entry). And it is programmable because you can type something like 1[proc sgn x {expr ($x>0)-($x<0)}] into the entry, and then in this example have it extended by a sign function... Do that in C... [slebetman]: One of the clearest example of this is how people are able to implement object oriented programming systems in tcl using nothing but tcl. Take a look at [snit] and [stooop]. The only other language I know that have managed this is lisp with CLOS. Another brilliantly sublime use of treating code as data is [rs]'s [let unknown know] experiment. And of course, my all time favourite effect of EIAS is the data is code paradigm (which is actually practically useful in production code). In most languages if you want to do something like load a config file or offer the user "limited" scriptability you need to implement a parser. In tcl all you need to do is define a syntax for your config file/scripting language to be compatible with tcl syntax (which btw is quite a common syntax for config files) and define procs implementing the config names. No need to [switch] on the attribute name/command name, just source the file and let tcl itself be the parser (if you're paranoid, which you should be, then you can use the safe interp to source the file). ---- [Category Concept] | [Category Example] | [Arts and crafts of Tcl-Tk programming] - is that a category? [RS]: No - it was the earliest cross-link, categories came later. I still often use when I don't want to think about categories :)