Michael Schlenker has very succinctly stated the need for a rich standard library for Tcl in several usenet postings
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:
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 have they own stdlib :(
May 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 this observations disapoint me sometimes very much. I 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 sintax, it does not overloaded with different features, but the best Toolkit is not Tcl, it's Perl. Why? Because it simple (yes, simple as a Toolkit!) and very effective. What do I mean? I mean the next:
Development with Perl 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 modules I need :(, I often switch to Perl, too often. Only when I need to make GUI I use Tcl.
I would like to call Tcl community to direct efforts not at yet another standart library, but at automation of development process:
Look around, we have interpreter version 8 but we have no normal development environment(I don't mean IDE or RAD)! Success of the Language depend on 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. It looks like unsed and dropped. Why? May be because no any documents in standart Tcl distribution describe how to use this archives.
I call to members of TCT: please direct your attention to network repository and module building system, at current stage of Tcl evolution it's more important for future of Tcl. More important than Language itself now.
About libraries: I think no need in yet another library, better idea is split current tcllib in 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.