Picol, a Tcl interpreter in 550 lines of C code

Picol, a Tcl interpreter in 550 lines of C code(oldblog.antirez.com)

111 points by wooosh 3 years ago | 13 comments

goddstream 3 years ago |

The Picol code has always been a fascinating read, until you get to the comment /* XXX: escape handling missing! */ and realise it won't escape/eval stuff inside strings, so you think ha! and roll up your sleeves and get tapping ... then you think ha! I could just improve that bit of code, and ... before you know it the sun's coming up and you didn't feed the dog last night. Speaking for a friend, obviously.

antirez 3 years ago | |

It happened to me as well, and that was the result: https://github.com/msteveb/jimtcl

Libraries written for Jim Tcl became the foundation of Redis.

actionfromafar 3 years ago | | |

But it’s so simple. All I have to do is divine from what I know of you. Are you the sort of man who would put the nerd snipe source code into his own repo, or his enemy’s? Now, a clever man would put the source into his own repo, because he would know that only a great fool would reach for what he was given. I’m not a great fool, so I can clearly not choose the source in your repo. But you must have known I was not a great fool; you would have counted on it, so I can clearly not choose the source in my repo!

bsder 3 years ago | |

This is the same thing that happens in Scheme/Lisp when you note that the tiny thing you're working on doesn't handle dotted pairs so you dig in and ...

The next thing you know your tiny code has tripled in size and now spews so much gark that you have to go optimize your garbage collector and ...

zserge 3 years ago | |

Huh! Falling into exactly this trap, I ended up writing a tiny Tcl interpreter for the embedded systems years ago: https://zserge.com/posts/tcl-interpreter/

tyingq 3 years ago | |

It also doesn't do well with strings that have a null character in it. Which would stop basic stuff like being able to copy/read arbitrary files. So, neat, but not practical outside a narrow subset of problems.

unwind 3 years ago |

Meta: this really needs a (2007) or something, to signify that it pre-dates Antirez creating Redis and stuff.

I had time to think "wow, I also want to create some world-famous infrastructure software, rock that world for a bunch of years, then (semi?)retire and blog about 3-hour C projects!!". :) It's always very interesting (to me) to see what people end up doing after a great success, so I thought this was it.

Then I read the early comments, understood that it was from before Redis, and went back to check. The only post date I could find was in the (Italian) tiny footer where it says "Pagina creata il Thursday, 15 March 07".

Edit: changed the suggested year to be only 2007.

antirez 3 years ago | |

Yes, indeed! I can confirm this post is from 2007.

082349872349872 3 years ago |

> Probably the parser should be rewritten in order to take less space, currently it takes almost 250 lines of code: this is too much and leaves little room for all the rest.

Wirth's PL/0 is also pretty much half parser, and I've noticed the same phenomenon in a couple of my projects.

I believe this is why we had no-grammar languages in the early days (LISP, APL, FORTH) — if the rest of the language is small enough, parsing looks like bloat.

blippage 3 years ago |

I've used Picol a couple of times in some of my microcontroller projects as a command language. Its advantage is that it is easy to compile and link to without a lot of rigmarole.

sea6ear 3 years ago |

I did a stupidly straight translation of Picol into Python about a year ago [0].

I'm daydreaming about doing another translation of it into Racket, but I don't think I'll have free time until January or February.

It would also be interesting to see about doing a version of it in Lisp Flavored Erlang.

Similar to some others in the comments, I may have just nerd sniped myself (again).

[0] https://github.com/connorberry/PicolPython