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 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:
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:
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.
SC: CANTCL hasn't seen active development in a while mainly because I've not had time to work on it but also because no-one else seems to be interested. My enthusiasm might be enhanced if even one other person stepped forward to contribute to the project. I will work on it again when time permits at least for my own purposes, but that probably won't be until mid-year.
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.
LV writes: so the intent of this page (other than the excellent comment by daapp) is that a parallel distribution to tcllib, for compiled extensions, is needed? Is that what is meant when the term "modular standard library" is used? And the intent there, I suppose, is to create a source library (or a binary library) which contains basically a set of extensions that those working on the project see as essential to most Tcl programming? And for the most part, the initial work is to be centered not on writing new extensions, but to work with the authors of existing code, where possible, to organize code into a single downloadable file that can be compiled. Is that a correct summary? And for those cases where extensions are already being maintained in CVS, some discussion about whether to move the code into this new project, or make use of the code where it is, needs to take place.
I guess I come back to daapp's comment, and ask this question:
Is the problem that people want to find entire CVS repositories and cannot find them? Is it that the code does not already reside in CVS or some other control mechanism? Or is the problem, as daapp discusses, that people want to be able to find a distribution point (ala CPAN) for releases of the code (preferably with some info as to dependencies)?