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 its 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: * Regularizing the grammar (e.g., "list length" and "list create" instead of "llength" and "list"). * Regularizing object concepts: [cfile] rather than "file", to make the usage of object-like commands match Tk. * Removing hideous warts: the :: is the worst offender in this respect although . from Tk is another example -- since Tcl already has the basic idea of a list built-in, the idea of listing a series of nesting things in order from some common ancestor (global namespace, top window, whatever) should use that same syntax rather than inventing another. Rather than set ::a::b::c foo, set {a b c} foo. Rather than .top.menu.file, it should be { top menu file }. It has been my experience that this item alone confuses more new users than any of the basic Tcl concepts. ::a::b::c looks like C++, but .a.b, which also looks like C++ or C has a completely different meaning. The need to parse and maintain these constructs also adds needless bloat to the language. * Conform arrays and dicts: the distinction between arrays and dicts makes sense to programmers who have used Tcl for ages but they are new landmine for new users. Ideally, these should not be separate, since they are the same concept in two different syntaxes. It might be argued that "dict" is the right way to go and that "array" as such simply dropped. The reason for this will become obvious in the "expr" section following. * expr is a pain in the butt. It was painful enough in its first incarnation as an expression evaluator since it is way verbose and it and its associated [[ ]] obfuscate code. However, since adding bytecode compiling to the language the need for adding yet another layer of { } not only obfuscate further, they introduce a new landmine for newcomers: a { } expression that manifestly ''does'' do $-replacement! Furthermore, whenever expr ''does'' encounter an unknown identifier, it doesn't need the $ to know it needs to look it up. Similarly, the fact that an identifier is suffixed with "(" should be clue enough for expr to look up a tcl proc if the identifier is not in its internal function table. If we get rid of arrays, it becomes simple to use ( ) to delineate things to be evaluated with expr. Thus, something like: "string range $foo [[expr $index-1]] [[expr $index+1]]" becomes just "string range $foo (index-1) (index+1)" - ''much'' easier to read. * Patterns are a similar pain - the overloaded use of both ( ) and [[ ]] make it very difficult to write patterns properly and to read them once you have written them. Ideally some method of delineating patterns - perhaps < > - and the use of @ rather than $ (or some similar choice) for eol, would enable us to embed patterns much more gracefully than we now do. * Macros. It should be possible to define a "macro" - similar to a "proc" - that gets a shot at a command ''before'' it is byte-compiled. These would provide ways to, for example, allow a command kicked off to "unknown" to be resolved and byte-compiled without further performance penalty. * Make the language friendlier. The "set" command is a particular offender here, it is more verbose and different from the "normal" way of doing assignments without offering any great improvement in utility. I offer two possible improvements here: [let] or ->. -> works just like ";" except it notifies the parser that the value of the command it just evaluated should be copied into the variable name that follows. Thus, [[string range $foo (i-1) (i+1)]] -> substring. * And add ''real'' comments - I'm tired of the old "why can't I have unbalanced [[ ]] in comments?" questions. It really isn't that hard to have the parser eliminate "//.*$". 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, I do not intend to make any suggestions on the feasibility of implementation or even technological superiority (yet, anyway). 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" (using Critcl type technolgy, perhaps). Then we could say: "TCL9 supports itself + any version of TCL and TK you have installed on your system or deployment" 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. ----- One other quick suggestion would be the deployment with the new core of a sort of Upgrade Assistant for old code. Since things like this *never* work 100% and very often not without some tweaking of the new code, calling it a translator would be foolish. The "Assistant" would take an older TCL script, and make several levels of suggestions for code changes: 1. TCL9 Syntax Compliance 2. Obsolete command replacement 3. TCL9 Technology advances Thus, the programmer can obtain suggestions for at the very least running his script in a TCL9 interpreter without compatibility options. More experimental suggestions could also be made, encouraging the programmer to use new TCL9 commands and constructs. Either way, a potential win for both the developer and TCL9. ---- This page is to discuss what we'd like to do to Tcl if full backward compatibility was not a factor. [XX] I wonder, then, if i should move my suggestions above to another page, possibly the TCL9 wishlist. I entered them here because it was the original comments about the situation being resolved with a "fork of a kind." I agree with the principle of keeping the best, fixing the worst, and refining the implementation of the language into an elegant implementation of the "TCL idea" without being bound by design decisions of the previous generation. I view my suggestions as a way to make possible what is actually being discussed on this page without compromising the smooth transition path and reliable operation that *needs* to be in effect. So in my opinion, it is relevent to this page, though I am probably biased so I'll leave this bit of housekeeping to the judgement of others. ----