Pretty neat that it was implemented in less than 600 lines of C.
One drawback, though, is that you couldn't use it for arbitrary data. The strings seem to be mapped to C strings, so variables can't contain nulls. No way to express a null in a string literal, either.
Edit: antirez (redis creator) also made a tiny tcl interpreter...actually a little smaller than Partcl. Has the same issues with null chars: http://oldblog.antirez.com/post/picol.html
When I made partcl, I also wrote a brief post of why+how I implemented it: http://zserge.com/blog/tcl-interpreter.html
I tried to keep data representation separate from the main interpreter code, so if one needs to use binary data or real lists - he may only rewrite a small part of code.
If fixed properly, it would open the door to non-string types - like, you could have a type that's entirely opaque to tcl, just a void * or whatever, accessed only through functions. This might even actually end up being a step up compared to "proper" tcl...
This would push the line count over 600, but I bet it would still come in at less than a nice round 1,000, while making the thing a lot more useful.
(I have a side project that's starting to feel like it might need a scripting language. And I always liked tcl. Must... resist... rabbit holes...)
One drawback, though, is that you couldn't use it for arbitrary data. The strings seem to be mapped to C strings, so variables can't contain nulls. No way to express a null in a string literal, either.
Edit: antirez (redis creator) also made a tiny tcl interpreter...actually a little smaller than Partcl. Has the same issues with null chars: http://oldblog.antirez.com/post/picol.html