Purpose: talk about the interface and interaction between Tcl and TclX, and the best way for them to evolve into the future.
R. T. Wurth finds loop, commandloop, keyed lists, cmdtrace, edprocs, profile, lvarpush, system, and set and string operations indispensable.
Is it better to
CMcC: One option, I've been thinking about is gutting TclX and moving some of the more useful functionality into tcl core.
To that end, here are some think-pages:
The most frequent request is to move the TclX signal handling commands into Tcl.
TclX is a grab-bag of useful functionality, a proving ground for new/nice facilities. They should be handled independently, so I have three categories.
Another suggestion that's been made in the past is to create an extension that provides Tcl bindings for the most useful Posix functions.
DKF: Useful Posix stuff (to me) has been: all the signal stuff, fork/execl, id and times. YMMV. :^)
Andreas Otto: (23 may 2004) I ported tclx to 8.4.6
the current state of tclx :
the future of tclx:
future tclx extensions:
CMcC: Oh! I've been charging along trying to gut tclx, and not aware of your work, Andreas.
I'd like to see a lot more of tclx's functionality incorporated into core tcl, because a lot of it is very useful, and the hassle of making an extension is probably beyond a lot of newbie tclers.
CMcC: My personal feeling is that something between 1. (gut tclx) and 4. (keep some integrity) is best, but I think some of the file commands, for example, should completely disappear into tcl's file command. That kind of leaves the signal, posix and miscellaneous facilities. Signal and posix could remain as distinct modules, but they ought to be tied more to the core IMHO. Which leaves us with miscellaneous category (help and such) which aren't core facilities, things like keyed lists which are superseded/obsoleted by new tcl developments (qv dict), and useful stuff like intersect3 which should be in tcllib.
That's how I see it, anyway ... move useful stuff into core, leave tclx behind because it now has a long history and can't function as a new facilities proving ground because of the need to remain compatible. Then another such extension collection can be made, and the cycle continues.
I hope this isn't perceived as cruel or uncaring, I just think TclX has succeeded beyond the point where it should be kept distinct from the core. Although creating a distinct binary tcllib umbrella and calling that TclX is a very appealing concept, it would necessarily have to carry along TclX's baggage, wouldn't it? I love the idea of a binary tcllib, but I think it has to be a clean break with TclX because otherwise we might perpetuate the disparate interfaces, the obsolete commands, and other stuff which TclX compatibility entails.
I hope the idea of a binary tcllib succeeds so well that whole slabs of core tcl functionality could move into it.
Personally, I don't love the idea of extensions containing generally useful, and sometimes essential functionality, because they are hard for newbies to get and load, and their lack impoverishes tcl relative to some other systems and languages.
The best possible solution would be for a packaging system for tcl which made it trivially easy to acquire essential functionality. Tcl doesn't have it, Python does, Perl does, and that's (I think) why they are perceived more positively. We're not close to having a universally workable trivially easy distribution/packaging solution for tcl, (StarKit notwithstanding), so the only reasonable solution is for tcl core to cannibalise essential functionality.
Moreover, if TclX, expect, et al are to provide essential functionality, I think they need to take over all of the functionality for Tcl - it makes no sense to me to have some essential (or at least wildly useful) file functionality in Tcl, and some in TclX, without a coherent interface. The extensions aren't modular, and to get the functionality people need, they have to cobble together disparate extensions, using incompatible build systems, with different degrees of interoperability (e.g. TclX hangs tclhttpd, apparently.)
There's possibly a reasonable question of how much of the TclX functionality TCT want to own, given the added maintenance workload. It seems to me that tcl core has to either support concepts like file completely, or not at all. If tcl core can't/won't support file in all its possible expressive richness, then it should simply move all file functionality into a distinct module.
The other consideration is that at least some of TclX is a thin wrapper around standard POSIX functions. Things like critcl are useful in that, as userid shows. This raises questions of packaging and building ... which are interesting challenges to the way we look at tcl.
I didn't intend to turn this into a political rant, but ... stuff happens :)
DKF 20080108: Note that I plan to turn file into an ensemble, but it might not have happened quite yet.