What, that's super cool! I've also been working on a from scratch implementation of TCL for firstclass multithreading, and it's been really fun learning all the edgecases that show up. I've gotten a lot of the core components working, but man is reference counting a pain in the neck or what. Are you doing a mostly one-to-one port, or something more novel? I've been working on my design to dramatically lower double indirections for lists. It's a little sad that a list contains a list of pointers pointing to another list. So much indirection! So I'm trying an experiment where all non-list/non-dict objects are contained directly after the head dict object in memory. It took a crash course in buddy allocators to finally figure out how to store objects, but it's really cool how I can allocate 8 contigious objects, set the first to the dict metadata, and all other items are the dict's objects. One cooler thing is if one of the dict's items is still borrowed somehere (ref_count > 1), the dictionary will dissolve into individual allocations, and all non-shared items are freed. Then, the new dict will reference them, as they're now normal objects.
> Are you doing a mostly one-to-one port, or something more novel?
Step 1 is a one-to-one port of all the non-I/O, non-OO stuff. I've got it down to a single skill for Opus 4.5 and now it's just a matter of turning the crank and keeping an eye on it.
Step 2: add more functionality for interactive use for humans/agents. Things like defining the syntax of commands, a completion engine, a help system. Essentially all the things you'd expect from a modern shell experience, but with a bring-your-own-UI approach.
> but man is reference counting a pain in the neck or what.
Maybe this is a bit more novel: since the only use case is embedding, and the host language already has dicts, lists, and other data structures, I'm just leveraging those. In the Go version of Feather, dicts are Go maps; in the JavaScript version they are backed by lists of pairs (to preserve insertion order)
> Are you doing a mostly one-to-one port, or something more novel?
Step 1 is a one-to-one port of all the non-I/O, non-OO stuff. I've got it down to a single skill for Opus 4.5 and now it's just a matter of turning the crank and keeping an eye on it.
Step 2: add more functionality for interactive use for humans/agents. Things like defining the syntax of commands, a completion engine, a help system. Essentially all the things you'd expect from a modern shell experience, but with a bring-your-own-UI approach.
> but man is reference counting a pain in the neck or what.
Maybe this is a bit more novel: since the only use case is embedding, and the host language already has dicts, lists, and other data structures, I'm just leveraging those. In the Go version of Feather, dicts are Go maps; in the JavaScript version they are backed by lists of pairs (to preserve insertion order)
Note that the name might be confused with an old project: https://wiki.tcl-lang.org/page/Feather .