The callback way is more generic and prevents consing when you don't need to store the resulting node list. You may want to simply print something or maybe modify the node in-place, for example.
Authors found themselves fighting with control flow graph modifications and replaced mutable graph with immutable one, modified by zippers. They achieved speed up of 11% in optimizing transformations, some of which they were unable to implement in mutable version. E.g., more complex optimizations were working faster.
> In C++, this could be achieved if all local variables were in fact std::shared_ptr captured by value.
So, in C++ you do actually get to pick what happens and there are plenty of options but for our purposes here all we want is a (mutable) reference capture.
However, experienced C++ programmers would never do this because C++ is all foot guns all the time, so you can express what you meant and it'll blow up and cause chaos because now our reference outlives the thing referred to. Oops.
In Rust we can write what we meant, but instead of the program exploding at runtime the compiler will politely point out that this can't work and why.
And so armed with the knowledge from that, we can (in Rust or with C++ although it's harder to spell in C++) write something that'll actually work.
We could move the captured variable. In Rust we just use the keyword `move`, now the captured variable is gone, moved inside the closure, and so as with the Tcl the same variable (the one moved into this closure) is used each time the closure is called, and if we make another closure that's got a different captured variable.
But we could do the "shared reference" trick, that type is spelled Rc in Rust.
The Wiki[1] is one of the primary "hang out" spots, although it's a bit different from usual online communication. But there's a lot of mutual commenting, small articles and utilities etc. on there.
"The European OpenACS and TCL/Tk conference will be in Bologna/Italy/Europe on July 10 & 11 2025." - this is crazy. Seems there are still people using OpenACS in 2025.
They did have a recent language update after awhile. That may have triggered some folks to look into it again. There is sometimes a HN effect where an initial post triggers some interest amongst enough users to get us new posts for a few weeks and then things tend to die off again. I've seen this with a lot of the more obscure languages like APL.
It would be cool to have a Tcl revival though (although I don't see it happening - I'm not in the community though so hopefully someone more informed can post). The language itself seems more capable than most give it credit for. I'm more of a Python fan myself, but can appreciate Tcl after reading through a book on it and writing a few scripts.
For those who are not aware, Tcl is actually part of standard Python distribution through TKinter.
There are many things Tcl has built in that are quite amazing, like a robust virtual filesystem support, reflective channels, and less known these days Starpacks (stand alone runtime) that bundle sources with the binary.
I am current working on bringing back kitcreator for an AI project that uses Tcl as a scripting environment over llama.cpp.
Roy Keene is the original author, and has done some really clever stuff here, like encrypting the VFS appended to the executable. I added compression to this. It provides some manner of obfuscating sources.
And actually, I am also working on using tohil to compile a static Python and load it as a Tcl extension, with the goal to have standalone Python applications bundled with their sources and completely loadable from within the VFS. This will provide a means to bundle TKinter with a “frozen” Python app.
Thank you and GP for the recommendation, just bought the book, seems pretty good! Now I wonder whether it's a good idea to replace my shell with tclsh... seems a lot more sane than bash/zsh.
Definitely would be interesting to use it in that way! The nice thing about Tcl is the syntax is clean (in brevity and understanding). Basic features like piping, file globbing, encoding conversions, compression, and so-forth are intuitive.
If you’re interested, I have various Tclkits available for download on GitHub. I have added dependencies to them like TLS for HTTPS and so-forth. It can be convenient to have them standalone; the TLS extension here is bundled with the ca certs from libcurl.
And here’s an example how I use the kits in the CI build. It uses the kit it builds to push the update using the TLS extension along with the GitHub REST API:
Bash is pretty good for really small scripts. Anything bigger and I have reached for Perl, Python, or Tcl in the past ... depending on what IT had installed on the server.
I last got help on the IRC channel (bridged to Slack, because I don't know IRC).
In the most recent big version update there was what I'd consider a breaking change regarding text encoding handling, but it was possible to go back to the old behaviour with an additional parameter .
I introduced it into some of our release tooling in the mid-2000s. Easy to integrate, easy to understand, unsurprisingly good string/text handling, expect was very useful, and it’s not going to be used by anyone else, so no worries about version conflicts.
It ran successfully largely unchanged for around a decade.
Strange, I've been attending the EuroTcl conferences for a few years now, I don't remember any of the presentations I've seen being related to EDA - https://www.eurotcl.eu/pastevents.html :-/
it's a language that's trivial to implement because it's well designed and simple, it embeds very nicely, and it's fantastic for use as a debug shell and to implement guis. it's a great technician's language, if you work with technically-minded people who aren't necessarily programmers, it's a great way to hand them deep interactive power without the footguns of a forth.
I would say it's cleverly designed. Well designed? Hmm, would a well designed language have such a basic flaw as comments that can only be used in very specific places?
I understand where they came from here: the Scheme-like obsession with purity (the enshrined Endekalogue, now Dodekalogue) didn't mesh very well with traditional comment.
Yeah, Tcl has its design warts, but I don't think it has that many remaining that can't be fixed via metaprogramming. Even the popular Python manages to frustrate me with its idiotic statement/expression divide (they doubled down by making match() a statement...) and constant need to convert between generators/iterables and lists.
Thing is that R6RS Scheme (or R7RS-large if it comes out one day) is basically a better Tcl if you only consider scripting and don't need the event loop. If Tcl had played its cards right, it'd have competed with fish/rc/nushell/powershell instead, it was really ready to be a better shell well before any other.
Despite that, I find article interesting. It shows that Tcl can truely be multiparadigm programming language.
Myself, I've implemented pattern matching [1] over algebraic-type-like values and used that here and there.
[1] https://wiki.tcl-lang.org/page/Algebraic+Types
The callback way is more generic and prevents consing when you don't need to store the resulting node list. You may want to simply print something or maybe modify the node in-place, for example.
[1] https://web.archive.org/web/20070417190836/https://www.eecs....
Authors found themselves fighting with control flow graph modifications and replaced mutable graph with immutable one, modified by zippers. They achieved speed up of 11% in optimizing transformations, some of which they were unable to implement in mutable version. E.g., more complex optimizations were working faster.
> You might wonder why you'd ever need such a strange behaviour, right?
Closures can also be used to return a group of methods that all act on the same set of variables; ie, objects.
> In C++, this could be achieved if all local variables were in fact std::shared_ptr captured by value.
So, in C++ you do actually get to pick what happens and there are plenty of options but for our purposes here all we want is a (mutable) reference capture.
However, experienced C++ programmers would never do this because C++ is all foot guns all the time, so you can express what you meant and it'll blow up and cause chaos because now our reference outlives the thing referred to. Oops.
In Rust we can write what we meant, but instead of the program exploding at runtime the compiler will politely point out that this can't work and why.
And so armed with the knowledge from that, we can (in Rust or with C++ although it's harder to spell in C++) write something that'll actually work.
We could move the captured variable. In Rust we just use the keyword `move`, now the captured variable is gone, moved inside the closure, and so as with the Tcl the same variable (the one moved into this closure) is used each time the closure is called, and if we make another closure that's got a different captured variable.
But we could do the "shared reference" trick, that type is spelled Rc in Rust.
Is Tcl having a revival? Anybody know where Tclers hang out online?
The Wiki[1] is one of the primary "hang out" spots, although it's a bit different from usual online communication. But there's a lot of mutual commenting, small articles and utilities etc. on there.
[1]: https://wiki.tcl-lang.org or https://wiki.tcl.tk
"The European OpenACS and TCL/Tk conference will be in Bologna/Italy/Europe on July 10 & 11 2025." - this is crazy. Seems there are still people using OpenACS in 2025.
I worked on a startup whose main language was Tcl, between 1999 and 2002, since then I hardly touched Tcl again.
Yet it has a special place on my heart and was one of the interpreters easiest to extend, in regards to the FFI API.
If you work with VHDL or Verilog tools, it is very well alive and kicking. Forums about HDLs are full of it.
They did have a recent language update after awhile. That may have triggered some folks to look into it again. There is sometimes a HN effect where an initial post triggers some interest amongst enough users to get us new posts for a few weeks and then things tend to die off again. I've seen this with a lot of the more obscure languages like APL.
It would be cool to have a Tcl revival though (although I don't see it happening - I'm not in the community though so hopefully someone more informed can post). The language itself seems more capable than most give it credit for. I'm more of a Python fan myself, but can appreciate Tcl after reading through a book on it and writing a few scripts.
I highly recommend The Tcl Programming Language: A Comprehensive Guide:
https://www.magicsplat.com/ttpl/index.html
For those who are not aware, Tcl is actually part of standard Python distribution through TKinter.
There are many things Tcl has built in that are quite amazing, like a robust virtual filesystem support, reflective channels, and less known these days Starpacks (stand alone runtime) that bundle sources with the binary.
I am current working on bringing back kitcreator for an AI project that uses Tcl as a scripting environment over llama.cpp.
https://github.com/tclmonster/kitcreator
Roy Keene is the original author, and has done some really clever stuff here, like encrypting the VFS appended to the executable. I added compression to this. It provides some manner of obfuscating sources.
And actually, I am also working on using tohil to compile a static Python and load it as a Tcl extension, with the goal to have standalone Python applications bundled with their sources and completely loadable from within the VFS. This will provide a means to bundle TKinter with a “frozen” Python app.
https://github.com/tclmonster/tohil
The previous edition of that book is the one I read lol. A great book. You can really feel the author's love of the language.
Thank you and GP for the recommendation, just bought the book, seems pretty good! Now I wonder whether it's a good idea to replace my shell with tclsh... seems a lot more sane than bash/zsh.
Definitely would be interesting to use it in that way! The nice thing about Tcl is the syntax is clean (in brevity and understanding). Basic features like piping, file globbing, encoding conversions, compression, and so-forth are intuitive.
If you’re interested, I have various Tclkits available for download on GitHub. I have added dependencies to them like TLS for HTTPS and so-forth. It can be convenient to have them standalone; the TLS extension here is bundled with the ca certs from libcurl.
https://github.com/tclmonster/kitcreator/releases/latest
And here’s an example how I use the kits in the CI build. It uses the kit it builds to push the update using the TLS extension along with the GitHub REST API:
https://github.com/tclmonster/kitcreator/blob/main/.github/s...
Bash is pretty good for really small scripts. Anything bigger and I have reached for Perl, Python, or Tcl in the past ... depending on what IT had installed on the server.
I last got help on the IRC channel (bridged to Slack, because I don't know IRC).
In the most recent big version update there was what I'd consider a breaking change regarding text encoding handling, but it was possible to go back to the old behaviour with an additional parameter .
r/TCL is worth a mention
It is unfortunately entrenched in the EDA industry. I have absolutely no idea why you would use it if you don't work in that space.
Because it works.
I introduced it into some of our release tooling in the mid-2000s. Easy to integrate, easy to understand, unsurprisingly good string/text handling, expect was very useful, and it’s not going to be used by anyone else, so no worries about version conflicts.
It ran successfully largely unchanged for around a decade.
Everything works. PHP works. Perl works. Bash works.
I like to use tools that more than merely work.
There's a reason nobody outside EDA uses it.
Strange, I've been attending the EuroTcl conferences for a few years now, I don't remember any of the presentations I've seen being related to EDA - https://www.eurotcl.eu/pastevents.html :-/
It’s included with Python in the form of Tkinter, the MacPorts package manager is written in it, and it’s also used by Cisco IOS for scripting.
Just FYI when people say things like "nobody like this" or "everybody does that" they don't literally mean 100.00%.
It is, for many people, an absolute pleasure to work in.
it's a language that's trivial to implement because it's well designed and simple, it embeds very nicely, and it's fantastic for use as a debug shell and to implement guis. it's a great technician's language, if you work with technically-minded people who aren't necessarily programmers, it's a great way to hand them deep interactive power without the footguns of a forth.
I would say it's cleverly designed. Well designed? Hmm, would a well designed language have such a basic flaw as comments that can only be used in very specific places?
I understand where they came from here: the Scheme-like obsession with purity (the enshrined Endekalogue, now Dodekalogue) didn't mesh very well with traditional comment.
Yeah, Tcl has its design warts, but I don't think it has that many remaining that can't be fixed via metaprogramming. Even the popular Python manages to frustrate me with its idiotic statement/expression divide (they doubled down by making match() a statement...) and constant need to convert between generators/iterables and lists.
Thing is that R6RS Scheme (or R7RS-large if it comes out one day) is basically a better Tcl if you only consider scripting and don't need the event loop. If Tcl had played its cards right, it'd have competed with fish/rc/nushell/powershell instead, it was really ready to be a better shell well before any other.
------
To be honest, Common Lisp is the only language I've ever seen get this right without compromising on said purity by specifying the reader (parser): https://www.lispworks.com/documentation/HyperSpec/Body/02_.h...
Comments are then just the result of a readtable entry like any other, allowing this kind of voodoo:
absolutely, i don't even consider that a flaw. i dont like EOL comments stylistically.
I totally agree, but TCL comments are even more restricted than that.
Pretty cool seeing folks show up about Tcl, tbh I messed with it ages ago and never thought people were still this into it
I don't get to use Tcl at work anymore, but I adore it. I use it for command line stuff on a regular basis