Cloverfield - The Gathering

The purpose of this page is to gather all information related to Tcl language improvement, on this Wiki or the WWW.

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.

On Things holding Tcl back, people make a lot of good points for and against a Tcl9-like revitalization. See also Tcl NG, which is "an adjunct to the page Things holding Tcl back" by PWQ.

Found the following page NexTcl + NexTk - a possible roadmap for Tcl/Tk development [L1 ] on the Tcl 9.0 WishList page. It shares many points with Cloverfield on non-technical issues (marketing, revitalization...).

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 [L2 ]. 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 [L3 ], 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 [L4 ].

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).
}

Emulating closures in Tcl

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}, because the semantics is different: it evaluates the delayed expression when the string rep is generated, whereas {delay} only does when the value is accessed (and it also plays nice with argument expansion).