** Announcement ** The official announcement for the Cloverfield project can be found there: [Cloverfield - Announcement] ---- ** Goals ** Along with the general goals listed in the above announcement, here are a few more specific technical goals: *** Language *** Improve the Tcl language syntax on several points to address common criticisms as well as implement missing features. For example : * 'Fix' the comments; * Auto-expand the first word of a command recursively. This will simplify currying and can give great results if namespaces become regular commands (spaces would thus become a valid namespace separator); * Improve variable access : allow e.g. `$$var`, and subscript access such as `var[[1]]` or `var(a)` along with interfaces (see Data structures below); * Allow variable references using the syntax `$&var`. This can fill the gap between current value/reference access semantics, e.g. `lindex` vs `lappend`, and solve many mutability vs. immutability problems; * Add a new quoting rule using parentheses, and drop the `list` command as we know it. For example, `(a b $c)` should be equivalent to `[[list a b $c]]`. The semantics of quotes and braces is preserved (minus changes needed for e.g. comments). Incidentally, this is the same syntax as LISP. * Extend the metasyntax pioneered by the argument expansion operator. This is the most controversial syntax change, but is unfortunately needed by the nature of some changes, like references or LISP-like delayed evaluation. * Define a syntax for specifying references. This can be used for example to serialize circular references, or keep references to variables that go out of scope; for example, `{ref self}(a {ref self}{})` specifies a list whose second element points to its parent. For more detailed information, see [Cloverfield - Tridekalogue] *** Data structures *** 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. *** Runtime *** 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. ---- ** Related information ** See [Cloverfield - The Gathering] for all other pages related to language improvement. ---- ** General Discussion ** [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. ---- 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? ---- ** Specific subtopics ** *** Data structures *** **** Ropes **** 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. ---- [DKF]: Experience with strings-implemented-as-trees in the past makes me point out that you'd better make sure that you take care to keep the trees balanced. Otherwise you'll have terrible performance. And using C arrays of characters seems to actually work quite well in practice... [FB]: flat strings (ie C arrays of chars) give good performances in Tcl's current context. Object sharing, COW, the lack of references, and the impossibility to build circular structures, all these factors suit flat strings perfectly. However, when you introduce references and mutability, you cannot use COW semantics anymore, because changing an object's value implies invalidating the string rep of all objects that reference it. This can represent a huge performance hit, as data sharing are obviously more likely with languages that allow references. With rope structures, you only have to invalidate the substring that has changed, by rebuilding the tree (or one of its leaves in the simplest cases). Moreover some platforms like Java only provide immutable strings, and allowing string mutability implies a huge performance hit. This can be a serious problem if we want to implement a Tcl interpreter over the JVM. In this case, a rope structure can be modified but the underlying data is stored in immutable string. You can read the following paper for more info on a real world rope implementation, especially section 'C Cords': http://www.cs.ubc.ca/local/reading/proceedings/spe91-95/spe/vol25/issue12/spe986.pdf ---- **** See also **** * [Tcl9 and annotated strings]. *** Comments *** See [Cloverfield - Comments] *** Word modifiers *** See [Cloverfield - Word modifiers] *** References *** See [Cloverfield - References] ---- [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. [FB]: Thank you. I understand your concerns about the amount of noise generated on RecentChanges. It is true that there have been a lot of Cloverfield-related changes on the feed, but the reason is simply that the project has just started and that I'm indexing and cross-linking a lot of information on the Wiki. Anyway I'll going to start moving some of the above pages back here so as to limit the impact. Rest assured that my goal is not to hijack or disrupt anything but to generate discussion and push Tcl forward. ---- !!!!!! %| [Category Language] |% !!!!!!