Jim Tcl – A Tcl Interpreter | Hacker News Reader

Jim Tcl – A Tcl Interpreter

jim.tcl.tk

There's something about Tcl that I like. It managed to take a few simple rules and parlay that into a language that seems like it's much more complicated than it actually is.

When someone asks me about Tcl I always tell them to just "man Tcl" (if you have a Mac, it's already installed). Look at that man page—that's the entire syntax of the language. Everything else in the language is commands. It's almost lisp-ish in its simplicity, but it feels like a "normal" scripting language.

Even the base language was always made to be embeddable and extensible. I always loved that when you created a new Tcl command, the C function to implemented it looked like:

   typedef int Tcl_CmdProc(ClientData clientData, Tcl_Interp *interp,
                           int argc, const char *argv[]);

IE, just standard "main()" style code with a couple extra args. (The newer Tcls have a new API that doesn't use strings for everything but that's a little more complicated).

This interpreter seems even easier, and that's saying something.

> typedef int Tcl_CmdProc(ClientData clientData, Tcl_Interp * interp, int argc, const char * argv[]);

> IE, just standard "main()" style code with a couple extra args. (The newer Tcls have a new API that doesn't use strings for everything but that's a little more complicated).

Tcl "Objects" (versus the pure string implementation) do honour the power, simplicity and "spirit" of Tcl just as well as your string example...

   int myCommand (ClientData clientData, Tcl_Interp * interp, int objc, Tcl_Obj * const objv[])

The "objects" (I quote this for a reason) are not object-oriented constructs, but a compound structure (we're talking the internal C implementation here...) to manage what a Tcl component is. The computing model is (and always has been) "Everything is a string (eias)", which is to say, there are no ints, floats, chars, etc in Tcl -- just strings. Non-string values are coerced correctly at runtime. With an object though, the "native" value for an entity is stored internally so that it doesn't have to be computed at every access. So, storage that is "9" will have (int)9 tucked away in the Obj if one is doing integer work with it. If you switch to float, it will have 9.0... you'll have fast access to the computed native value as long as you don't interleave accesses that want a different native type -- such as trying to retrieve an int, then a float, then an int, then a float... in this case, the objects "shimmer", in Tcl parlance.

Like a lot of things Tcl (which has a long history), much of peoples recollections come from a long time ago... in this case, the new object (versus pure string) representation came into effect in 1999[0] with Tcl 8.0.

In my opinion, the objects are just as easy to use as strings, and bring some nice performance improvements to the table. Otherwise, Tcl is still as fun to use today as it's always been, while it's also getting interesting tweaks and additions as time goes on.

[0] http://www.tcl.tk/software/tcltk/8.0.html#What%27s%20New%20i...

Edit: formatting

Jim is a nice lightweight reimplementation. I will say I was a bit disturbed at how the built-in commands are haphazardly scattered in the code when I had a peruse through it once. They are just randomly mixed in with other internal functions with no care for rational organization

A year or two ago I ran into the fact that classic TCL still only supports UCS2 as it internal text representation. In particular, that any unicode characters outside the basic multi-lingual plane, like many popular emoji, are not supported.

It can convert to/from utf-8, but any codepoints outside the BMP get mangled (each byte of the utf-8 considered an independent codepoint) and there's really no way to detect this happened in TCL. There's really nothing you can do.

I hoped it didn't, but unfortunately it looks like Jim Tcl has this same problem: http://jim.tcl.tk/index.html/doc/www/www/documentation/utf8/

(Also, Jim Tcl is originally written by antirez!)

For an example of what you can do with this tiny TCL lib take a look at: https://github.com/dimkr/packlim

People joke that moving from parens to brackets is easier to type, but its true, I coded faster in tcl than I do in clojure.

I will hazard a guess that many HNers know Jim's author through another pretty piece of software he wrote: Redis. It feels a little odd that Jim is not the scripting language of Redis.

There has been some talk that Tcl 9.0 will build on top of Jim or on top of ideas from Jim. I don't know what current status of that is.

Reply on news.ycombinator.com