The official announcement for the Cloverfield project can be found there: Cloverfield - Announcement
Along with the general goals listed in the above announcement, here are a few more specific technical goals:
Improve the Tcl language syntax on several points to address common criticisms as well as implement missing features. For example :
For more detailed information, see Cloverfield - Tridekalogue
Use ropes as the internal string representation. Ropes will use B-trees of immutable strings. This will give fast concatenation, slicing, insertion, and should dramatically reduce the memory usage and data copying.
Use interfaces (à la Feather) instead of Tcl_Obj. This should eliminate most cases of shimmering.
Implement the runtime on existing virtual machines. Primary target is LLVM. Secondary target could be Java, .NET, Parrot. LLVM is the most interesting solution since it gives access to JIT compiling, platform independence, native performances, and allow total control over the internal model (contrary to JVM). Moreover, other languages such as C or C++ are already supported, which means that we could get cross-platform Critcl-like features for free.
To achieve the goal of VM independence, internal data structures should be sufficiently high level.
Provide a VM-less, purely interpreted reference platform for embedded and small footprint solutions.
The runtime should provide advanced execution modes such as coroutines, stackless, lightweight threads, etc. See Radical reform of the execution engine for some ideas.
See Cloverfield - The Gathering for all other pages related to language improvement.
George Peter Staplin: Hi FB! I think you have some good ideas. I've read some of your code for TkGS. I'm hoping that you can get developers behind this project, and it doesn't become moribund. I am interested. Cloverfield is a good name, and I think it gets away from many old misconceptions about Tcl.
FB: Thank you! Yes, I hope Cloverfield will get more attention. TkGS scope was a bit too narrow to really get developers on the project. But I've learned a lot working on it, even if the project never completed due to lack of free time (building a family needs a lot of commitment). Anyway I think it is a bit obsolete now, since most of the work involved the creation a new graphic layer, and I feel that Cairo would do the job perfectly. I even had the project to port Tk to Cairo a few months ago, but given the success of Tile I came to the conclusion that Tk no longer needed significant improvements (at least for now), whereas Tcl was losing ground, so I moved on to what became Cloverfield.
About the name: I chose Cloverfield only a couple of days ago after realizing that the date for the announcement was 18-1-08. But prior to that I made a list of possible names, see: Cloverfield - Alternate names
Lars H: Wow, I think there isn't a single thing on that list that doesn't strike me as completely wrong for Tcl. Fascinating! Well, as long as you're just starting it up as a separate project I suppose I can happily ignore all of it…
FB: I don't want to sound too harsh, but after reading your contributions to all the discussions I found on this wiki regarding language improvements, you seem to be very conservative when it comes to anything that might impact the Dodekalogue. Frankly, I don't think that auto-expansion of leading words is totally un-Tclish, given that the same suggestion have been made by several reputable Tclers such as DKF of NEM, and that it currently requires unknown hacks to work (see Let unknown know and An implicit {*}$ prefix). And the use of parentheses has been debated in Tcl 9.0 WishList, see #67. I understand you were against this change, but you should also concede that this change would greatly improve readability.
Lars H: No, it would not noticably improve readability.
FB: Let's have a look at the following code:
# Tcl: set l [list \ [list 1 2 $somevar] \ [list 3 4 [someproc]] \ ] # Cloverfield: set l ( (1 2 $somevar) (3 4 [someproc]) )
Don't you agree that the latter form is more readable? Moreover the former is more error-prone (you can easily forget a backslash), and this is a simplistic case. Removing the noise created by list and backslashes leaves only meaningful data. Add new-style comments and you get a more declarative way of defining data vs. the old procedural style. I also feel that the new style would be faster to parse and interpret, because the whole tree is now a single word, versus a collection of subwords in the former case (and this is a very important condition for the proposed reference declaration syntax).
LES Dude, if this entire business is about making Tcl more popular (and it looks like it is), a little more effort spent on Tk/Tile and a handful of useful and good-looking desktop applications would probably be a lot more effective than any sort of fragmentation. Fragmentation is usually a very good strategy to stifle an endeavor.
KJN Better desktop applications would clearly be an asset. The OLPC adopted GTK as its main graphics toolkit, even though Tk is a much better fit for a resource-constrained system such as OLPC; but it had no choice, because GTK has the applications (Abiword, Gnumeric, Firefox...), and Tk does not.
However, it is always worth thinking about what we would like Tcl to become. Most suggestions will be explored and eventually rejected (see pages on this Wiki for many examples); a few will be adopted, after lengthy debate. Fragmentation has not occurred in the past (except for a few brave souls who still use Tcl 7 or even 6 because of their smaller footprint) - there aren't enough of us to maintain two major codebases.
See Cloverfield - Data structures
See Cloverfield - Word modifiers
When casting about for a language that isn't object orientated, I happened upon Tcl. Apart from perl, which is also seems to have become frozen in time), this seems to be the only one. But it's like stepping back in time. As far as I can see, there's one book that's modern(2004) and all the rest are from about 1997. I presume when they say they work with windows they mean 98? There doesn't seem to be an equivalent of CPAN, eggs, gems either, or if there is, it's not obvious. But that goes for the whole language, not obvious. It's like its pitched a C programmers and that's it. The only thing that will work is a compelling application that takes a share of mind. Other than that it will remain an overlooked language. It's problems are, no books, no tutorials, no obvious way to do things. Perhaps it's had its day, legacy only, isn't that the way of it?
CMcC I've been persuaded to lift the RecentChanges suppression of Cloverfield, which I have done. I still think it's a walled garden, but ... let a thousand flowers bloom. Please don't feel that it can't be refactored, should people want to do that, and be aware that I'm considering some kind of repetition filtering for RecentChanges which would preclude all the Cloverfield changes appearing on the same day, just a signal-to-noise issue. But above all, I behaved inhospitably, and that's not good for a wiki.