"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 strings.
It is brought to life in commands, which are lists (which are a view on strings).
In data, everything is a string, and many strings can be evaled 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 sourced 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 <Return> {catch {expr [string map {/ *1.0/} $e]} res; append e " = $res"} ;# RSWhat 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 :)