Yesterday, after I wrote up some observations why Tcl and Parrot weren't necessarily the best fit for each other, I talked to Jeff Hobbs (The Tcl Guy).
We had a very good chat. Turns out that I am mistaken. My understanding of the Tcl world is heavily focused on legacy apps -- the kind of stuff that's running in the Tcl analog of 5.005 or 5.6.x, and will never be upgraded. There's an entirely different world that's living in the 8.x series of releases. Although some Tcl projects may rely on the characteristics of the Tcl implementation, Tcl releases since 8.0 have had macro shims (the "Tcl stubs" interface) that look like direct C calls, but are actually wrappers that add a layer of indirection. So porting Tcl code that uses C code that uses exported Tcl functions in C should be a simple case of updating the stubs once to run on top of Parrot. Not only would a port to Parrot be advantageous, but updating the shims should be a small amount of work.
Pretty damn nifty, that.
And it gets better. Back in the bad old days, Perl/Tk involved some herculean efforts by Nick Ing-Simmons to glue Tk to Perl without using an intermediate Tcl interface. That's because the only real Tcl interface involved stuffing strings into the Tcl parser to push Tk to do stuff. The new (since 8.0, in use ~7 years now) Tcl_Obj interface provides C-level access to Tcl primitives and completely circumvents the bad old way of creating strings for Tcl to evaluate as Tcl scripts -- for every operation. Jeff has released bindings that talk to the Tcl APIs directly to poke Tk without messing with double interpretation or Nick's herculean efforts. The best part is that it is much faster and has a lot less memory overhead.
Pretty damn nice, that.
