The purpose of this page is to gather all information related to Tcl language improvement, on this Wiki or the WWW.
CMcC Speaking of gathering: since there's no real constraint on wikit page size, I think it would be more convivial if all the Cloverfield pages were combined into a few. Perhaps one. At least until the vapour condenses.
The practice of dumping a bunch of pages onto a wiki is called creating a Walled Garden and is not widely liked. See http://c2.com/cgi/wiki?WalledGarden
FB According to the reference above, Walled Garden typically make few links to and from the rest of the Wiki. So it's a bit unfair to qualify the Cloverfield related pages as a walled gardens given that the current task is precisely to interlink all pages that may cover some of the areas of this project, and that it only started a few days ago... On the other hand I don't want to give the impression that I want to hijack anything by pasting Cloverfield links everywhere.
Regarding the page size, I think this is a matter of taste. As Cloverfield covers many areas, I think it's a better idea to develop separate ideas on distinct pages than on a single monster page, because it keeps the discussions consistent and it eases change tracking. I would have done differently if Wikit supported page anchors but it is presently quite difficult to point to a specific section within a page. But anyway the number of pages will remain limited. I've just rewritten the main Cloverfield page using a more structured style.
See also Tcl 9.0 WishList and all things Tcl9 related.
Just found Tcl/2 as well. Perhaps the first task of the Cloverfield project should be to gather all information related to language improvement? Cloverfield could be an umbrella for all these micro-projects/features/suggestions. I have the feeling that many people share similar views on all these problems, but that there is an overall lack of communication and organization. Cloverfield could be the sparkle that ignites the engine...
And yet another couple of discussion pages: Unified Programming Language, and If I were to complain. The more I dig into the wiki, the more I realize that these are very long standing issues, that everybody wants change, that most people agree that some things must be started over, but nobody makes the first move. Tcl needs a vision.
Another one: Tackle! This one dates back from 2004. I think I've opened a kind of Pandora box. For the better I hope.
Tcl9 and annotated strings: ropes seem to perfectly fit the needs for "A smarter string representation". Added FB comments there.
Paul Duffin's Thoughts on the Future of Tcl here [L1 ]. He discusses replacing :: with space as a namespace separator, and allowing auto-expansion of leading words. However this causes problems with variables and global scoping. I'd suggest keeping the existing namespace separator along with space to accommodate with all cases.
The space vs. C++ -style :: reminds me of the heated discussion about the introduction of namespaces in Tcl8 back in the days (you can still find this discussion on Google Groups [L2 ], look for the thread name "Namespace notations"). I was already a proponent of spaces as separator, and namespaces as regular commands (I was also young and stupid, so please don't pay too much attention to some of my messages ;-). The general consensus was to preserve the syntax and semantics of [incr Tcl], because the introduction of namespaces was supposed to be the first stage for the integration of [incr Tcl] into the core, and it was the dominant (single?) OO extension at this time.
The page Let unknown know provides code for an unknown handler to recursively auto-expand command words. The code is trivial, which is a tribute to the simplicity of Tcl. See also An implicit {*}$ prefix.
Watch for the discussion on variable substitution syntax in the Dodekalogue. The Cloverfield - Tridekalogue tries to bring a bit more consistency on this point.
Discussion around null and TIP #185 [L3 ].
Continuations: could they be implemented with {delay} and closures? One can "already" implement generators with {delay}:
# squareGenerator returns a list whose first element is the square of its argument
# and second is a delayed expression for the next iteration.
proc squareGenerator {i} {
# Note that only squareGenerator is delayed. Expr is evaluated immediately.
list [expr {$i*$i}] {delay}[squareGenerator [expr {$i+1}]]
}
# Initialize the generator at 1, and loop 10 times. This should print all
# squares from 1 to 10.
for {set i 0; set gen [squareGenerator 1]} {$i < 10} {incr i; lassign $gen current gen} {
puts $current
# Variable gen now holds a delayed call to [squareGenerator <$current+1>], which will
# be evaluated when it is first substituted (=> lassign).
}Lazy objects for delayed processing gives a package with functionalities similar to {delay}, and raises interesting questions regarding exception handling. As it is a Tcl_Obj-based hack, it might prove less deterministic than {delay}.
Runtime improvements: Radical reform of the execution engine, tcor - A Tcl Coroutines Extension, co-routines, Filament - A very lightweight thread package