Purpose: to outline and prioritize features and functionality that developers or users find missing in Tcl. As you think of things to add to the list below, please insert the things in the appropriate place. If someone is aware of code (patches, extensions, procs, etc.) which fulfills the need, please drop a URL or Wiki reference in place so that we know that requirement has/can be met.
Also, feel free to add, enhance, or expand on the categories and/or definitions below. I just took a first crack at this as a brain storming start place.
DKF: This page needs to be rewritten so as to separate out features that are best as (possibly existing) extension packages, and those that really need to be in Tcl itself.
Missing Features - these have to do with how Tcl the language itself works, syntactically, gramatically, etc.
Critical Missing Features
Insert items here which are so needed in Tcl that until the feature is present, the language isn't suitable for use in your particular problem domain. If you have a lot of description, background, etc. drop in a Wikit or URI pointer to a seperate location.
Important Missing Features
Items inserted here will add to Tcl features which are needed to resolve major development or support issues.
Useful Missing Features
Items inserted here improve Tcl in significant ways.
Features Found In Every Program
Functions or commands you find yourself adding to every program you write. Sure, there's no need to add them to the core...but wouldn't it be nice if you could forget about them?
A command that returns a guaranteed unused command name, optionally using a template for the name.
An [lshift] command: return the first element of a list stored in a variable, removing it from the list and updating the variable (surely this would be faster in C?)
proc lshift varName {
upvar 1 $varName L
set res [lindex $L 0]
set L [lrange $L 1 end]
set res
} ;# RS who likes to roll his own ;-) Alternatively, using [K]:
proc K {x y} {set x}
proc lshift varName {upvar 1 $varName L; K [lindex $L 0] [set L [lrange $L 1 end]]}
DKF: 8.5 has lassign which makes this sort of thing trivial:
BR - finally: The finally part of try/catch/finally. Manually writing correct code for resource deallocation and re-throwing an error is somewhat tedious and error-prone (see example and a simple proposal on the catch page). DKF: I'd quite like this too, but 8.5 now gives you enough bits and pieces to script this.
RS 2007-05-25 - In Tcl scripts used in pipes, I frequently code:
proc puts! str {if [catch {puts $str}] exit}
This is because when the output of the script is piped through head or more, an unbecoming error is thrown when the pipe closes down:
error writing "stdout": broken pipe
while executing
"puts ...
I'm not sure whether "broken pipe" is a correct error to throw. All I know is that most utilities finish quietly when their stdout is closed, and the puts! workaround above provides the same behavior to my scripts. DKF: This is an expected/unexpected error issue; the "broken pipe" error comes out of the POSIX layer, and it's up to you to define how you wish to respond to it. Using "puts!" as above is probably the quickest fix.
Missing Functionality
These items have more to do with extensions / bindings / etc. than with the language of Tcl itself. Often Tcl is taken to task as not having a batteries included mentality. However, I still haven't seen those in community who believe this come to an agreement on requirements that would satisfy them. Working on a 'sumo' software development kit, as I keep hearing people endorse, isn't a useful task if a set of requirements aren't clearly identified. What I find as a sufficient set of extensions may not have much overlap with someone else's needs. Identifying what is needed allows the community work towards that goal. Below, list the extensions that one would want to find in a single, huge, all inclusive extension distribution.
Note: if you see something listed as having never been written but you know that it is available, feel free to move the entry down and add to the entry the appropriate pointer to the package.
Critical Missing Functionality
What we need here is a list of needs that have not even been written yet, as far as the writer knows.
Documentation and examples based on Functionality of frame and toplevel -container to enable swallowing of external X desktop applications, xterms, etc. (DKF: Some good examples of doing this here on the wiki would be good too...)
Better Data Structure support, with garbage collection where appropriate (8.5 brings dict)
True Multi-dimensional arrays (does nap satisfy here or BLT's data vectors? How would nested lists be insufficient?) (DKF: Also, dicts are nestable)
Garbage Collected Reference style data objects (this is possible: specifically we need to stop Tcl from losing references as easily as it does). [This is a controversial issue. Tcl does some things better than other languages because it does not rely on references for constructing data structures.] Jim has garbage-collected references.
Better Cross-platform ability to print out GUI components (DKF: Nice, but seems to be hard due to different printing models on different platforms. This awaits someone with serious amounts of time to work on it...)
Rich clipboard types (DKF: We already support this on X, though you have to do more work yourself. It's on Win or OSX where I think this is pressing, and yet tricky.)
Plugin style browser functionality, to allow seamless download and launch of Tcl/Tk application without a seperate install step (perhaps making use of starpacks?)
More help from tclpro's ProWrap to figure out what extensions can be included and which can't and help resolve the issue
An http client package that supports async requests (DKF: It already does; it's just that DNS lookups are blocking...)
An http client package that supports persistent connections (DKF: Isn't someone working on an enhanced http package that supports HTTP/1.1?)
Lazy evaluation support (DKF: I think we shouldn't do this; we should just say that Tcl is an eager language.)
Transmission of events/bindings between subwidgets of a megawidget
Support for lists of pure strings (more details is needed here)
Generate procs from a string (why doesn't eval fill this need? Or proc?) (DKF: Or apply?)
Documentation development support in the core
Cross-platform ability in Tcl to get just one character from stdin. (DKF: We can do it using read, but currently need hackery to put stdin into raw mode first. TIP#160 covers this, but I've been too busy to work on it...)
Named colors (similar to named fonts) and the system colors with names. (There is TIP#154 [L1 ], but Tile may have obsoleted that.)
Option sets
Ability to use all Windows (or other OS) native widgets - in the way that the MacOS X team is providing Aqua support (See note at bottom)
general software-generated event dispatch system, with value substitution and bindtags management, independent of Tk. Michael McLennan has something called a trigger command that may be relevant.
Continuations combined with Tcl level events (What arecontinuations?) ("... a way to nest calls to VWait in a way that the outer calls can wake before the inner calls do. That's the difference between continuations and subroutines.)
ONC RPC/Sun RPC and rpcgen support (DKF: In the core? Why? Do it as an extension first, please.)
Ability to use an internally generated bitmap as a Tk cursor.
Code to recognize a master pkgIndex.tcl, maintained so as to allow Tcl to skip the pkgIndex.tcl discovery process (DKF: How do modules interact with this?)
Introspective access to line number of code being executed. (TIP #280 [L2 ] provides this.)
Introspective access to commands associated with a particular loaded package
Some form of synchronization, inter-process (i.e. the lock/mutex/.. is visible in other processes). Something like the mutexes in thread, but then not just inside a process. You can see people find ways around this here How do I manage lock files in a cross platform manner in Tcl and Serializing things via file locks. Note the work involved to make something that will hopefully work on all platforms, and the trouble (what if we crash, the lock file remains and everything hangs; how do we find a free port for the socket, and how do other invocations of the same program know to use the same port, etc). This is difficult, and very difficult to do cross-platform, which is exactly why you'd hope your tool(s) would make it easy. Tcl should... (DKF: Tcl should... leave this to an extension?)
Important Missing Functionality
What goes in this part of the list would be functionality currently not distributed in the centralized package known as Tcl, but which people consider essential to be distributed. (DKF: Which people? The mix seems odd/eclectic...)
One or more Object Oriented Extensions
This assumes that such a thing is of interest to people. Alternatives to including this functionality into Tcl itself are:
incr Tcl [This one is on its way into the core distribution - if only someone steps forward and leads the work effort to make it happen.]
Provide http 1.1 support in Tcl's default http support (see TclSOAP for a beginning towards such support).
Specific Functionality available in some existing extension
An ftruncate or truncate command to truncate an open file to zero bytes or optionally to X bytes. (This is now chan truncate.)
A general database interface, under which a person could plug in specific hooks to Oracle, Sybase, Postgres, msql, odbc, etc. without having application changes needing to be made. Work on this has gone on with tclodbc and [fill in other extension names here] (DKF: SQLite has a lot of how I think such an interface should work.)
Useful Missing Functionality
In this category are those things which if available would be pleasant to have, or even important in some cases, but, in general, are not needed.
Extended digit math support
(for integers, Tcl 8.5 provides this in the core)
Mpexpr(DKF: Note that this extension will not be co-distributed with Tcl itself for license reasons. Basing something off libtommath would make for best integration with Tcl, and the license is nice and friendly...)
a port of the various widgets available for Perl/Tk but which are not currently available for Tcl/Tk (DKF: Being...?)
UDP and multicast sockets handling (in the core - hopefully as versatile and elegant as the current sockets implementation) (DKF: Question is, is the channel idiom right for this? If not, a new idiomatic messaging layer is needed, and that's tricky to think of.)
Tiled backgrounds in widgets
Ability to attach user data to an event - particularly virtual events - so they could be used as general message passing mechanism. (DKF: Done in 8.5 for virtual events.)
Ability to treat an event more like an object
Ability to overload expr's operators, to add things like complex number calculation support. (DKF: This is hard to do. Very very hard.)
tclhttpd (What in the world does this mean?) (a web server written in pure-Tcl, multi-threaded, easy to deploy and to use ala PHP)
Ability to execute Tcl commands from a command line invocation of Tcl (Currently, tclsh leaves all command line switches to the domain of the tcl script being executed - changing this would break existings scripts. It is rather trivial to write a tcl script that provides this kind of functionality - see owh - a fileless tclsh for one example)
Ability to generate image and font names so collisions can be avoided without reliance on remembering to specify some sort of prefix. (DKF: For images, this is trivial; just leave the name out from image create...)
Ability to apply some proc/command to each character of a string without having to a) split the string into a list of single character elements or b) looking up the string index each time through a loop. The first means that huge strings have to be duplicated in memory and the second means that huge strings require longer lookups than needed. [Actually, the second also duplicates the string in memory, as the string gains an internal representation for fast indexing.] Basically, the idea would be a means of treating a string as if it were a C/C++ byte array, only ideally the array would treat unicode characters as unique elements; ie $stuff(index) would hyperquickly find the right character. (DKF: Splitting into individual characters is specially optimized anyway; doing better now requires writing a [foreachCharacter] command.)
In a recent Slashdot article asking which cross-platform GUI toolkit is the best, I found this post by someone: [L8 ]. Granted, this is a personal opinion of someone, but scroll to the bottom and read what is said about Tk. No native widget support and lack of widget selection. It's a point that will be brought up over and over again against us. If we could do this, we would have a real advantage over every other toolkit listed. Consider it.
Uhhhh... the poster of that comment is entitled to his own opinion, but not to his own facts. Tk has used native widgets since release 8.0. What's that 5 years now?
Really? Why are my buttons still gray and square on Windows XP? I'm talking about true, native widget support. We've gone part of the way, but until apps can look truly native on modern, skinned operating systems, we're not there. Applications still look foreign.
LV Anyone up to brain storming? I was thinking today - what changes/additions could one imagine adding to Tcl so that either a) the program was less likely to have bugs or, probably more realistically, b) the process of identifying and fixing bugs was significantly easier.
pdt: I'd quite like a -normalize option for the source command, for convenience:
source -normalize someDir/aFile.tcl
And a 'variables' command, again for convenience, which works like the global command:
variables aVariable bVariable cVariable
RLE (2012-09-08): You omitted telling those of us who are unable to remotely read your mind what the function of a "-normalize" option to the source command would be.
Re: a "variables" command which works like global, if by that you mean the fact that global takes plural variable names and makes them all accessible, and variable takes plural name/initializer pairs, then you can create your own "variables" command right now with a small proc:
proc variables { args } {
foreach var $args { uplevel 1 [ list variable $var ] }
}
This will likely only work from inside namespace procs, not at the namespace top (outside of any proc, but inside the namespace), but at the namespace top having single line variable commands associated with descriptive comments is often a good idea.
pdt The -normalize option would expand the filename, equivalent to: