Back when Tcl 8.4 was released (2002), a paradigm was established according to which the Tcl 8.x series was almost at an end; there would be another minor version upgrade (Tcl 8.5) to take care of some minor itches, but after that all development effort would be focused on Tcl 9.0. It wasn't so clear what the Tcl 9 series would bring though (beyond a reform of octal numbers), so it became somewhat mystical, with several more or less radical language reforms proposed (many of which would make Tcl 9 far less compatible with Tcl 8 that Tcl8 is with Tcl 7).
As it turned out, things didn't go according to this plan (but its mere existence may well have been instrumental to the way things happened). Concretely, Tcl 8.5 didn't get released until 2007 — over five years after 8.4 — and when it came it had so many new features that they would probably have been enough for two or three minor version increments, including
and much more (see Changes in Tcl/Tk 8.5 for the full list). Why is this? Well, since it "was going to be the last", lots of people wanted to put in "just one more feature", and as it turned out, there were plenty of improvements that could be had within the Tcl 8 series. Still, when 8.5 was finally released, it was clear that there would have to be an 8.6 as well (for the sake of TclOO), and as 8.6 is approaching feature-freeze, there are still several outstanding issues which shouldn't have to wait for 9.0, including:
See also ActiveState of Tcl 2008 for a summary of the state of things in October 2008.
George Peter Staplin: July 13, 2004 - Tcl 9.0 feels like something just beyond the grasp of reality. There are many ideas for what needs to be done, but most ideas from what I've seen aren't being actively worked on. I can't blame anybody for that though. We work on what we want to -- Tcl is free after all.
I've talked with Joe Mistachkin about JIT for Tcl 9.0. I've come to realize it's quite a bit more complex than my JIT for Forth, because of Tcl being so dynamic. I'm actively working on a prototype design.
Salvatore Sanfilippo and I talked about BigNum support. He even has some C code that implements such a thing. There is also: Proper integers for Tcl 8.5 or 9.0 and Proper integers implementation. There are several existing packages that already implement BigNums, but one has a license restriction (GPL/LGPL) and the other uses strings and I've been told/read is much slower than native CPU integer operations. I've written little prototypes that use the x86 opcodes add/adc to deal with larger integer types, but more design will obviously be needed. As it turned out, bignum support came already with Tcl 8.5.
LV Is the purpose of this page to summarize whom is working on features that are waiting for Tcl/Tk 9.0? It might be worth taking a pass through the TIP list to see which ones are tagged as being for 9.0 ...
George Peter Staplin: The purpose behind this page is to bring Tcl 9.0 closer to reality. I want to know what others are doing to reach this goal.
LV Fair enough - take a look at the TIP list. Basically anything that people plan on making it into Tcl / Tk 9 should have a TIP submitted...
FB: I've created a project on SourceForge dedicated to everything Tcl9-related:
http://sourceforge.net/projects/tcl9/
Currently it only holds the mailing list for Cloverfield but I'd be very happy to host other projects as well.
cliQ - 2016-09-19 01:50:51
You could skip the idea of a JIT and go straight to compilation to machine code (like golang does). Then work could focus on optimizing the compiler instead of adding every bell and whistle.
Instead of going down into assembler and starting from scratch the guys over at gnome designed Vala to template their language and map it to C then compile to machine code through C's compiler. Then another person designed the Genie Language to also use the Vala compiler, so two programming languages as different as Python and C++ are from each other use the same machine compiler, which is really a modified C compiler.
C compilers like GCC can be really slow and painful. Go's compiler is so much faster it's refreshing.
If tcl were able to compile to machine code I would use it for almost everything involving interfaces then use Go to fill in the gaps. Go is designed to handle some asynchronous server stuff really well. It's blah with big numbers, but I'm sure it will mature in time. Go compiler is wicked fast. You might think about templating tcl structures to map to golang, and use their compiler, which has not had any optimization work yet, yet leaves GCC in the dust in its barely beyond beta state. This might make tcl faster than Java after a decade of optimization fixes.
If we had a good scripting language that was blazing fast, we could finally stop filling up the world with python eggs and broken gems.
@cliQ, it's as if these words were spoken from my own lips. I live begrudgingly in Python and Ruby day to day, while my nights are spent writing Tcl and C. Critcl was a beautiful step in the right direction, but if Tcl 9 were to include Quadcode, dare I say changer of games? -- xk2600