You can speed that Tcl snippet up considerably by putting braces around the expressions, e.g., `expr {$n - 1}`. On my system it went from ~22 seconds to ~4 seconds.
Without the braces, the expression gets parsed twice, once as Tcl syntax and once as Tcl `expr` syntax. Luajit is still going to be faster, but Tcl will do better than what you're showing there. (Not bracing expressions is the most common reason by why Tcl code runs slowly.)
In terms of tab-completion, you have to roll your own; and if you're trying to do it in the console, you're going to need to write your own REPL: the standard `tclsh` doesn't even have "readline" editing.
Back when I was doing Tcl regularly, I wrote a Tk "terminal" widget, and all my Tcl/Tk apps had a way to pop it up. Made life much easier.
hey, thanks! i should have known that and didn't. i've corrected my comment above since you corrected me so quickly that i could still edit it!
i feel like readline and tab-completion is pretty important to a good command language, and plausibly you want to integrate support for tab-completion into the design of the language itself rather than having to write a separate completer for each command
i'm kind of puzzled why tclsh doesn't have any command-line editing. maybe ousterhout's team was only ever using tclsh in emacs shell-mode or something like your tk terminal? as an exercise, i wrote a basic command-line editor in c in bed on my cellphone the other night. it took me an hour and a half and 120 lines of code (with a very narrow line length to fit onto the cellphone screen), and it supports arrow keys, movement by words, word delete, about a dozen keystroke commands in all, which is most of the ones i use. (though i really need to fix the cbreak handling and handling of wide lines to work reliably.)
Historically it’s because TCL uses the BSD license and GNU readline does not. But yeah, no reason not to implement an alternative.
As for speed, it’s less that everything is a string (internally, data gets stored as both a string and whatever it last needed to be converted to) and more because TCL is so dynamic that compiling it is hard.
There’s been some work on compiling to native though.
upvar and uplevel are a significant barrier to optimisation, but not to plain compilation — the hardest part would be autovivification of fresh up-locals, and even that sounds like an extra indirection could reasonably handle it?
EDIT: looks like tcl doesn't bytecode uplevel expressions, so I must be missing a catch?
yeah, what i was thinking of specifically was that they would be a major barrier to optimization, which is the benefit one hopes for from compilation
to be specific, it would be pretty hard to optimize a non-leaf procedure if any other procedure it called were able to violate any assumptions you'd made when optimizing it. elided redundant type checks, perhaps to specialize a proc? the proc it called changed the type of one of its variables. constant propagation? that proc changed the value of the variable you thought was constant. strength-reduction? likewise. you aren't going to get much dead code elimination without constant propagation. invariant hoisting? how are you going to figure out what's invariant if a proc you're calling inside the loop could change any of the variables used in it? register allocation? better have a way for upvar and uplevel to look up which register it was
Without the braces, the expression gets parsed twice, once as Tcl syntax and once as Tcl `expr` syntax. Luajit is still going to be faster, but Tcl will do better than what you're showing there. (Not bracing expressions is the most common reason by why Tcl code runs slowly.)
In terms of tab-completion, you have to roll your own; and if you're trying to do it in the console, you're going to need to write your own REPL: the standard `tclsh` doesn't even have "readline" editing.
Back when I was doing Tcl regularly, I wrote a Tk "terminal" widget, and all my Tcl/Tk apps had a way to pop it up. Made life much easier.