An interesting corollary to concept 5 (the fact that everything in Tcl is a string) is that this means that Tcl is actually homoiconic. It does it completely differently from Lisp, but still ends up in the same place: code and data have the same representation.
You can represent arbitrary C++ code as a string, too, and C++ has a fairly decent string type. Does that make C++ homoiconic? I wouldn't say so, because the structure of the code is lost when you represent it as a string and because C++ doesn't give you any way of using the code represented thus (e.g., there's no standard way to compile it). (The second of those isn't strictly part of what's meant by homoiconicity.…
Tcl has eval and uplevel, which allow you to easily execute arbitrary Tcl code within the language. You can easily implement macros, lambda expressions, list comprehensions, and more using these tools, if you want to.
Tcl is certainly not a toy language. I was introduced to it when running an eggdrop bot in the irc days, and I suspect for many of us was one of the first more feature complete languages we had no choice but to learn because we wanted to add custom functionality to our bots. I haven't kept up with it and enjoyed seeing there's still those who find it productive
Well, back in those days (around 1998-2002), when I was a kid at school, Eggdrop bots were a bit slow, which often became an important factor on channel wars: channel overtakes, net splits, and so on.
So we (some friends and me) created our own bot (with a very simple DSL) just for fun in pure C, and it was very fast (http://davis.sourceforge.net/). Of course, our DSL was never as well designed as Tcl.
TCL is great at being an embedded language, especially when you want something that looks like a DSL using safe-interpreters. (Basically, these are sandboxed interpreters with access to limited built-ins, plus any methods you might inject into the global namespace) TCL lends easily shell-like syntax so it is great for adapting your DSL to a REPL and even maps fairly cleanly to REST. Years ago, I built a REST-like API…
Since Tcl 8.5 (Dec 2007) interps have timed resource limits available for them.
bch$ tclsh8.5
% interp limit {} time -seconds [expr {[clock seconds] + 15}]
% while 1 {set a 9} ;# 15s elapse, then...
time limit exceeded
bch$
Tcl is certainly not a toy language. I was introduced to it when running an eggdrop bot in the irc days, and I suspect for many of us was one of the first more feature complete languages we had no choice but to learn because we wanted to add custom functionality to our bots. I haven't kept up with it and enjoyed seeing there's still those who find it productive
An interesting corollary to concept 5 (the fact that everything in Tcl is a string) is that this means that Tcl is actually homoiconic. It does it completely differently from Lisp, but still ends up in the same place: code and data have the same representation.
Interesting. I've never worked with Tcl, is it possible to write Common Lisp loop macro in Tcl?
I'm not familiar with lisp loop macros, but here is how this works.
For example the Tcl does not have try-catch-finally statement. If that happens in other languages you just need to accept it. In Tcl you can implement it yourself for example:
Back at the beginning of time I worked with Vignette StoryServer, which spun out of aolserver, one of the first "database-backed dynamic website" servers. The scripting language was TCL 7.something. I never encountered it again, but its elegance always stayed with me. Except for uplevel. Fucking evil.
It gives you the capability to extend the language itself, something you can't really do in most other languages. Tcl, Forth and Lisp are the only ones I can think of. These days you get "monkey patching" and so on, but it's nowhere near as nice.
Rebol, Smalltalk, Perl6 and Io are some other examples that have the capability to (easily & cleanly) extend the language itself.
Back at the beginning of time I worked with Vignette StoryServer, which spun out of aolserver, one of the first "database-backed dynamic website" servers. The scripting language was TCL 7.something. I never encountered it again, but its elegance always stayed with me. Except for uplevel. Fucking evil.
This is me, as well. TCL seems wierd and clunky when you come to it from C-derivatives, but once you get used to it, it's possible to write some very elegant code.
An interesting corollary to concept 5 (the fact that everything in Tcl is a string) is that this means that Tcl is actually homoiconic. It does it completely differently from Lisp, but still ends up in the same place: code and data have the same representation.
Interesting. I've never worked with Tcl, is it possible to write Common Lisp loop macro in Tcl?
I like tcl, but in my experience it's no lisp.
You can do macro like things in tcl, but very often the evals and uplevels all worked to make my brain hurt in ways that writing cl macros never has.
You can represent arbitrary C++ code as a string, too, and C++ has a fairly decent string type. Does that make C++ homoiconic? I wouldn't say so, because the structure of the code is lost when you represent it as a string and because C++ doesn't give you any way of using the code represented thus (e.g., there's no standard way to compile it). (The second of those isn't strictly part of what's meant by homoiconicity.…
Tcl has eval and uplevel, which allow you to easily execute arbitrary Tcl code within the language. You can easily implement macros, lambda expressions, list comprehensions, and more using these tools, if you want to.
TCL code in the form of a string is not a data structure the language provides you tools to manipulate past being able to execute it: if you wanted to write a macro you are forced to parse the string. While the code is conceptually a list of commands, each of which is a list of lists, with code strings as a special case of value that is itself really a list itself, those semantics are not what you type: code is a semi-colon separated list of lists (which could contain, of course, nested semicolons), and cannot thereby be parsed as any normal TCL data structure (nor can it trivially be run through split or something to get a normal TCL data structure). The square brackets are themselves somewhat special, and the white-space has complex semantics; variable substitution is a one-off feature. The language thereby has the property that code is data (so the example about C++ given by gjm11 was probably confusing, and even got me at first: I was about to write a response to him talking about how in C++ code is separate from data in a way that it isn't in TCL), but it isn't really "homoiconic" (which I then realized as I started working on that response, as it has been over a decade since I lived and breathed TCL, and all I had remembered was the abstract conceptual beauty as opposed to the nitty-gritty details of actually typing it; I started typing it, tried to manipulate the string, and failed). Due to this, I would quibble that you can easily implement macros: you actually first have to write a TCL parser (which people have done; if you search for tcl parser you find some TCL parsers written in TCL in the package index) to recover the structure of the code from the opaque data. Like, you may as well be coding in JavaScript: no one would claim JavaScript is homoiconic, but they do define a .toString() on functions which is supposed to return a string with code that could be evaluated back to a function... you technically can then write macros that take as an argument a function that is .toString()'d, run the code string through a JavaScript implementation of JavaScript's grammar (such as Narcissus), and then manipulate the result to return replacement code in the form of a new function... if you've ever worked in an actually-homoiconic language (like Lisp) this is a fundamentally different experience.