3 ms·
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 tha
by wduquette 2y ago
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.
- kragen 2y agoi can see how upvar and uplevel could be a problem for compilation
- 082349872349872 2y agoupvar 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?
- kragen 2y agoyeah, 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