I don't know TCL at all though I have implemented my own variation of tiny C in a handheld terminal I designed in the past which fitted nicely in 10KB in a PIC18F processor and 3K of RAM for the (compressed) basic so always good to see a different spin on other interpreters.

Your code doesn't actually compile in my MPLAB XC8 compiler but should be fixable so I may give it a go. I note there are no comments in the code but the explanation text should help.

That actually sounds really impressive. What did you gain from having a C compiler on an PIC? Was it used as your commandline interpreter?

whoops.. Would have been impressive if it wasn't a typo, should have read "tiny basic"

Was it assembly or c Lang?

See also TH1, which is the Tcl subset which Fossil uses for HTML templating:

http://fossil.wanderinghorse.net/repos/th1-sgb/index.cgi/wik...

It's about 6kloc. (I don't know how it compares to Picocl feature-wise.)

I made my own tiny Tcl thing a while back:

https://github.com/davidw/hecl

It ran on those Nokia phones that had a minimal version of Java (no floats!), which was kind of cool back in the day.

Is Hecl a tiny Tcl or a script language that borrowed a lot from Tcl? I checked your codebase it looks clean and easy to follow though my Java is rusty. I noticed you used 'instanceof' a lot, why not something like Visitor pattern ? You have not updated it for over 6 years , why? What is your future plan, and are you really look for contributors ?

TCL is an interesting idea. I have been a fan of MicroPython (https://micropython.org/) for a while. It's probably not as tight or efficient as Partcl but I think it may be a good contender for a comparison in your original article.

I was about to suggest the same; Micropython requires a little more flash/RAM (https://github.com/micropython/micropython/wiki/FAQ) than the authors goals but it's certainly no toy language despite the immature (but rapidly improving) tooling and libraries. I'm pushing to use it in more of my embedded projects - and have little desire to return to embedded C!

MicroPython also has an ESA sponsored port for their space hardened architecture and RTOS. And even more impressive, I'm writing my thesis about evaluating MicroPython for CubeSats.

Nice project!

Unfortunately, as with most interpreters written in C, afl finds segfaulting bugs in a few seconds. In your case at least empty variable substitutions are broken. E.g., entering

  $ foo

will crash.

I don't see why one would choose TCL over LISP-likes which can be made equally as efficient and are very simple to implement and optimize.

I imagine the C-like syntax is part of it. Tcl can be very easy on the eyes (though it can also be very hard on the eyes -- I'm looking at you, expr). It's an extremely down-to-earth language overall.

Objectively speaking, though, it seems like you're right -- historically, people have chosen Lisp-like languages over Tcl-like languages, as the latter are now mostly relegated to toy language projects like this one.

If you're interested, there's a little Lisp interpreter here:

http://www.sonoma.edu/users/l/luvisi/sl5.c

Memory management? Most Lisp implementations have a GC, while Tcl in its simplest form has no concept of a reference, and thus there is no need for a GC - everything is passes by value. For example, a simple `sl5.c` example below leaks all the memory it ever allocates.

Garbage collection isn't as big a detrement to performance as you might think. There are many realtime systems that run LISP. Like original LISP from the AI crowd. You might want to check out http://www.flownet.com/gat/jpl-lisp.html

(((((I can't either))))))

I was seriously confused by your message for a second:

https://en.wikipedia.org/wiki/Triple_parentheses

Mismatched parentheses