[Michael Schlenker] has very succinctly stated the need for a rich standard library for Tcl in several usenet postings http://groups.google.com/groups?q=g:thl2123827996d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=c5mb9q%242pd6o%241%40ID-102549.news.uni-berlin.de http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&selm=c5n813%243913h%241%40ID-102549.news.uni-berlin.de He says: Tcl has two competing groups in the discussion: The embedders that are concerned about startup time, library size, memory footprint and things like that on the one side, the "batteriers-included-huge-stdlib-in-the-core" fraction on the other side. Those targets are impossible to reach at the same time. So instead of making it a problem, try to create a virtue. a) Let the embedders factor out as much functionality as possible from the core into a modular stdlib b) Let the batteries group add as much useful functional as required into a modular stdlib ... and ... - Integrated, cross platform build system (TEA or better) - Useful documentation, probably doctools based - Stubs enabled if at all possible (sometimes hard or near impossible to achieve) - Export their own stubs table if their functionality could be useful - BSD license - Provides fundamental extra functionality (Thread, msgcat, XML, ASN1, TclX/Registry/ffidl/Twapi, KBK's localized clock, Datastructures, One or more OO-Systems, RPC-Support, TLS/Crypto,... ) To which I ([davidw]) would add: - The package should have a maintainer. - I would prefer to have one and only one OO system. Experimentation in this area has gone on for long enough. We need to provide something practical that works, for the "get it done" crowd. So, what shall we do to make this a reality? Something along the lines of: * Draw up some guidelines using this page. * Create a SF project * Decide on initial packages * Add code to CVS * Beat compile system into shape One of the things we will need to decide is what code to include directly in CVS, and which to import into the build system from other sources. Having seen tcllib in action, I do like the idea of having the source collected in one place, with the possibility of accessing different modules, as in tcllib, to foster "cross-pollination" and interest in the common library as a whole (maintainers fix bugs in packages that aren't necessarily their own). Anyway, just added this to keep the ball rolling. --- [daapp]: yet another library ... Every advanced Tcl programmer has their own stdlib :( Maybe it would be better to concentrate efforts on modules building system and network archive with automatic building and installation? I meet with Tcl/Tk in 1999, before I meet with [UNIX] and [Perl]. Since this time I trace the evolution of Tcl and these observations disapoint me sometimes very much. I will try to explain why. I differentiate a Language and a Toolkit. I think that Tcl is a very good Language: it has simple and consistent syntax, it is not overloaded with different features, but the best Toolkit is not [Tcl], it's [Perl]. Why? Because it's simple (yes, simple as a Toolkit!) and very effective. What do I mean? I mean the next: * standard automated mechanism to create new modules and it's distribution (h2xs for example) * one network archive with all available modules * standard mechanism to work with this archive (upload, search, download and build with dependencies) * often small Perl application consist of some '''use''' pragma and few lines of code Development with [Perl] is very comfortable, despite of heavy and difficult [Perl] syntax. I like to develop in [Perl], but I would like to develop more using [Tcl]. But when I remember how much work I need to do to install all the modules I need :(, I often switch to [Perl], too often. Only when I need to make GUI do I use Tcl. I would like to call Tcl community to direct efforts not at yet another standard library, but at automation of the development process: * build module system * central network archive * easy installation module procedure Look around, we have an interpreter at version 8 but we have no normal development environment (I don't mean IDE or RAD)! Success of the Language depends on the Toolkit very much, look at [Perl] for example. No [Python], neither [Ruby] or other popular scripting language approach to [Perl]. I know about [Cantcl] and [ETEN]. They both look like unused and dropped. Why? Maybe because no documents in the standard Tcl distribution describe how to use these archives. '''I call to members of TCT: please direct your attention to creation and maintenance of a network repository and module building system; at the current stage of Tcl evolution it's more important for future of Tcl. More important than the Language itself now.''' About libraries: I think there is no need in yet another library; the better idea is to split the current tcllib into smaller parts - network part, text processing part, ... Small notes: [smake] can be a base for something like Makefile.PL in Perl. [CriTcl] can be a base to replace autoconf and automake which are too complex. ---- [Category Dev. Tools]