The basic question is valid for any lovers of the language. I just wanted to know where I could provide some useful contributions. Maybe others free the same way and so the page was written.
So let's break this question up:
Personal observations and ideas
So what does the community think? I could just work on what interest me personally, but I thought I might let myself be guided at least a little but what the community think.
As far as what I can contribute, I will give you a very short resume and remember I'm not looking for a job.
This document summarizes all the feature suggestions from the Tcl community discussion. Each feature has a symbolic tag (for discussion) and a restatement of the idea.
Symbolic Name | Description |
ORGANIZE_WORK_GOALS | Figure out how and where to continue this discussion. (new 4/16/25) |
DO_WE_HAVE_SUPPORT | Figure out what kind of support we can get for this effort. (new 4/16/25) |
PRIORITY_LIST | Can at least some groups of devs produce priority list of efforts. (new 4/16/25) |
DEV_RESEARCH_TASK | Maybe some people can just research some of these task. (new 4/16/25) |
Symbolic Name | Description |
TYPED_VAL | Allow users to define semantic types for values (like typedef struct in C) to enforce model correctness and improve debugging. |
NAMED_ARGS | Support named arguments in proc definitions to improve readability and reduce reliance on position-based parameters. |
ARGS_NOT_LAST | Permit args to appear in the middle of an argument list, not only at the end. |
STATIC_ALLOC | Introduce ways to declare memory as statically allocated where predictable, for improved speed. |
ANNOT_SYNTAX | Expand syntax such as {*}{} with forms like {=}{} for expressions and argument annotation. |
DEV_DOCS | Need to document how some of the complicated parts of the code work to ease in new developers. (new 4/16/25) |
Symbolic Name | Description |
CHANNEL_REDO | Redesign the I/O channel subsystem to avoid repeated copying and enhance performance. |
ENCODE_FAST | Optimize common encoding/decoding routines to avoid multiple data scans. |
STRING_FAST | Improve performance of string operations (e.g., range, split) using techniques similar to list optimizations. |
LIST_INPLACE | Add more list commands that operate in-place (like lappend) to avoid unnecessary memory usage. |
STRING_SEARCH_FAST | Use faster algorithms (Boyer-Moore, KMP) for string first and similar searches. |
TIMER_WHEEL | Rework event/timer scheduling (e.g., with a timer wheel) to reduce latency and overhead. |
INTERP_FAST | Speed up creation of safe interpreters to make them more usable in performance-sensitive scenarios. |
CALLOUT_SPEED | Reduce overhead when calling C-implemented commands from bytecode. |
BYTECODE_RT_FAST | Improve bytecode runtime performance—under exploration by Donal. |
STATIC_CACHE | Add support for predictable caching mechanisms to improve speed for repeated tasks. |
Symbolic Name | Description |
STATIC_ANALYSIS | Improve or update static analysis tooling, including the Tcl Dev Kit (e.g., tclchecker). |
DEBUGGER | Provide a modern interactive debugger (e.g., revive or improve ProDebug). |
FORMATTER | Build or refine a Tcl formatter/pretty-printer that aligns with style guidelines. |
TREE_SITTER | Implement a TreeSitter grammar for Tcl for better syntax highlighting and tooling. |
LSP_SERVER | Create a Tcl Language Server Protocol (LSP) implementation for IDE integration. |
Symbolic Name | Description |
CMD_LINE_TCLSH | Support executing Tcl code directly from the command line (e.g., tclsh -e). |
SHELL_HISTORY | Add readline-style history and popup completion to tclsh. |
ASYNC_SHELL | Add event and background task awareness to tclsh. |
HELP_SYSTEM | Integrate a help system similar to TIP 194 with built-in command documentation. |
BETTER_EXEC | Replace or revise exec to handle Unicode, errors, and cross-platform issues more gracefully. |
GLOB_ALL | Add -all flag to glob to return hidden and non-hidden files in one go. |
NAMESPACE_TOOLS | Introduce namespace-aware tools (e.g., normalize, join namespace-qualified names). |
UNICODE_NORMAL | Provide Unicode normalization support using ICU or similar. |
DNS_ASYNC | Enable non-blocking DNS resolution in sockets. |
UNIX_SOCKETS | Provide full support for Unix domain sockets (also on Windows). |
UDP_SUPPORT | Add UDP sockets to Tcl for modern protocols like QUIC/HTTP3. |
LONG_PATH | Enable long path (64K) support especially on modern Windows systems. |
WIN_PTY | Replace Windows console with a PTY-style driver for better scripting. |
INTEGRATE_PARSER | Integrate TclParser into the core for consistent parsing and tooling support. |
Symbolic Name | Description |
TDBC_MAINTAIN | Resume active development and support for TDBC (Tcl DB Connectivity). |
THREAD_MAINTAIN | Provide ongoing maintenance and improvements for the thread package. |
AI_LLMS | Build Tcl bindings to modern AI and LLM libraries (currently Python-dominated). |
WEBUI_BINDING | Create Tcl bindings for the WebUI GUI framework (browser-based UI toolkit). |
ES_BINDING | Build a Tcl wrapper for ElasticSearch’s web APIs. |
SCOTTY_TNM | Revive or replace the aging SNMP libraries like Scotty and Tnm. |
TKPATH | Adopt and update tkpath, a modern canvas implementation with richer graphics. |
LEXBOR_BIND | Create bindings to the LexBor HTML rendering engine. |
Symbolic Name | Description |
SITE_REBUILD | Rebuild and modernize www.tcl-lang.org including navigation and styling. |
BROKEN_LINKS | Audit and fix broken internal and external links in the Tcl Wiki. |
OUTDATED_CODE | Isolate or flag content referencing outdated Tcl versions (pre-8.4). |
PACKAGE_INDEX | Create and maintain a central searchable index of Tcl packages and extensions. |
OFFLINE_TEACUP | Host ActiveState package archive offline and enable teacup to use it. |
(Earl, I took the liberty of moving your summarization to the top as it is much more lucid than the general discussion below).
APN Glad you created this page. I've noted my personal wishlist below but first couple of general comments. From the perspective of maximizing Tcl adoption, I feel the focus should be on extensions and bindings rather than Tcl itself (To be noted, I left out Tk there as I don't feel I have enough competence in Tk to voice an opinion). The exception is Tcl performance which I feel could benefit from some focus, particularly to make the 64-bit data size support in Tcl 9 actually usable.
Anyway, here where I would like to see work being done, in no particular order. Folks interested in picking some of this up might make a note here so as to avoid duplication of work. Of course, I hope others will add their thoughts and suggestions.
List of packages would of course be endless. Some that come to mind...
TWu - 2025-04-15 09:04:28
(1) To "More static analysis would be hard but good.": How about updates and binary builds to the open-sourced Tcl Dev Kit tools? It include tclchecker and tcldebugger, which has code coverage and profiling. But much is in C/C++ so I can't help.
To "A better exec, either TIP 424 or similar, to eliminate the many warts and misfeatures of exec.": Under Windows (and especially other languages than English, like German) it is often a hard work to get exec work correctly.
To "New -all flag to glob. ...": I highly be with You! Additionally there should be the possibility to ask for entry by entry as the actual glob blocks long time on large folders.
To "Long path name support ...": I use TCL/TK since 2004 under different Windows versions. Usually the long names are given back for each component of a path. If You need the 8.3-short-name there is file attributes, option -shortname. What do You miss else? But on file command under Windows there seems to be one or more bottleneck(s) asking some preferences/values. It seems file command open the file, which triggers the anti-virus unnecessary and thus slow down enormous. APN Modern Windows systems support path lengths as long as 64K and are not limited to MAX_PATH. That is what I was referring to.
To "Benchmarking": Please see my point (1) above to the subject profiling.
To "List operations": Since my first contact to TCL/TK I feel bad on list handling. Nearly all commands give their result back as "stringified" list. I don't know enough on the internals (Tcl_Obj), but on large lists and/or with large list entries, we move many bytes unnecessary. Maybe we could have list commands acting like arrays (doing more on references)? APN This is not true. Tcl does not use strings for its internal list representation. It only generates the string if you print it or pass the value to a command that operates on strings. TWu Yes, internal not. I want more like lappend, lset (both work in-place) and not like linsert, lrange, lreplace, and lsort (give back a new list). Maybe the byte-code-compiler do some optimization. But doing one step after the other there is always a "set l ..." between, doubling the needed memory and needs copying. I know of tcl::unsupported::representation and shimmering internal representation as well as tricks like ";#" at commands end to mitigate some special behavior (suppress output as string). Sorry, I was to unprecise.
To "More efficient string implementations": Not so hard like before, but the same for "string" sub-commands.
To "Accessibility support.": I have a hugh community of blind people. (See my web-site name / mail-address.) I can support on testing under Windows (and are willing to test).
To "Development tools", "Tcl formatter / pretty printer" and "Interactive debugger": Mostly I don't need a formatter and not print out source since a very long time. But if the Tcl Style Guide (respecting Tcl style discussion) is not enough, we can see... Please see my point (1) above to the subject tcldebugger.
To "Web presence - Rebuild www.tcl-lang.org." there is many to do - not only a refresh -
(a) find and resolve references from old / wiki.tcl.tk (internal) links and images to new place;
(b) this may include the move of the images or a recreation;
(c) the same for external links, there should be a tool (the real one not available/link itself broken!), see Broken Link Report and Category Broken Links;
(d) there are some pages with hugh content we can no longer diff (compare), these should be collected, and afterwards these shortened or splitted;
(e) additionally we could look for old/obsolete code for versions older than 8.4, a hint maybe the last changed date. These pages could be get into an own part of the wiki, so users can search for or without them as results. With this, obsolete or now wrong TCL/TK code is no longer spread around or explicitly marked as "outdated".
I try to help since some month and use the way-back-machine from web.archive.org to resolve after not found on two main search engines. But it maybe automated in many parts too?
(f) To "Package directory - list of Tcl packages and extensions": I can support on the latest and complete ActiveState repository. I host a 1 GiBy zip together with a script, allowing the Teacup to work locally with the content of the zip (as online no longer works, because of left https support!). It may a big and good base, and I can generate lists for the web presence automatically, I think.
Hope, this helps and give some further power - I'm happy to be in the Tcler's community! Greetings, TWu. APN @TWu, appreciate your taking the time to comment.