Tcl/2
There are a lot of arguments in favor of keeping as much backward compatibility as possible. This argument trumps a number of discussions the Tcl newsgroup has had over the years. This keeps the language stable but it also stultifies, and makes it much harder to make progress in new directions.
When this has happened in other languages, the situation was resolved with a fork of a kind - a second version standard. Modula/2, Oberon/2, and so on provided a relief valve that permitted the language to change and grow but avoiding the need to drag previous users, screaming and kicking, into an incompatible area.
This page is to discuss what we'd like to do to Tcl if full backward compatibility was not a factor. The primary objective is to reduce the overall conceptual load of the language (the stuff you need to remember to code efficiently) while increasing it's overall power. The bottom line goal: to make Tcl the most powerful and simplest language it can be. I'd like to focus on several areas:
I'm sure more ideas in this same vein have occurred to others. I'd like to explore these ideas with an eye toward producing a successor to Tcl that would vastly increase its power, readability, friendliess, and utility.
What are your ideas?
XX From the Marketing Division of the TCL Branch of the Sirrius Cybernetics Corporation:
The case for both sides is so compelling that the *ideal* answer for TCL/2 or TCL9 or whatever is to grab the best of both worlds and make it a feature of the language. Some rough possible ideas from the perspective of good marketing possibities follows. keep in mind that while I've tried to leave out the outlandish, do not make any suggestions on the feasibility of implementation or even technological superiority. Just trying to get the ball rolling...
So if I had to "sell" TCL/2 or TCL9, I'd want to be able to say that the next generation of TCL is unconstrained by previous code and/or design decisions (mistakes?) yet compatibility is close to 100%. How can this be accomplished, bearing in mind some of the strengths of TCL to begin with:
1. Compatibility engines as loadable extensions - the idea being that a programmer can add one line to an old program and have it work with TCL/2 TCL9. Of course, this compatibility can only be guaranteed for the core and for TCL code and not binary extensions. "Emulation libraries" could be provided that would allow TCL/9 to fall back to the language implentation represented by that particular library.
One attractive feature about this model is that there is no core bloat for compatibility. One downside is that (presumably) binary extensions would need to be distributed with the core. Key versions would need support in the core. What would be really neat would be a "generator" that could take an existing TCL or TK library and synthesize a compatibility module "on-the-fly".
2. Compatibility "switch" as part of invoking syntax for an interp or new command. The difference here is that the functionality of previous versions would be "encapsulated" in the core. One could activate such support by invoking a command during execution. This might bloat the core sizewise (though I have NO idea how much) but shouldn't cost much performancewise, and should cost nothing if not invoked.
I encourage those that know the mechanics of these things to show me up and come up with better implementation details. My point is that while there are downsides to both breaking old code *and* keeping compatibility syntax, TCL should innovate and do neither. Make any syntax changes necessary in the new language definition, and offer optional compatibility to older software and site users.