Hacker News Reader

Comment by normac | Hacker News Reader

Interestingly, Tcl was parsed the same way all the way up until Tcl 8.0 introduced a bytecode system in 1997. Each line was parsed right before execution with no separate parsing stage--your code could crash in the middle of executing from a syntax error.

Tcl is now about as fast as a typical scripting language and its implementation is regarded as a model of high-quality readable code. I wonder if John Ousterhout (the creator of Tcl) knew he was building a rough first system that he would need to rewrite later, or he really thought it was the right way to do things at the time.

(To be fair, Tcl is a whole lot simpler to parse than JavaScript and Ousterhout is a good coder, so even the pre-8.0 versions were fast enough to be practical for everyday scripting tasks.)

View on HN

Most shell interpreter follow this model, perhaps he started Tcl has an improved shell scripting system and only later improved it? It would explain some of the syntax choices which is fairly reminescent of c-shell and some bourne thrown in.

That's pretty much what Tcl is, even to this day. Ousterhout saw scripting languages as extremely high level tools used to issue commands to the low level code that does the heavy lifting. It's very much the same philosophy as shell scripts, except you implement new commands as extensions to Tcl instead of command line programs, and it all runs in the same process.

Of course, the language has matured and now it's also usable for building rich and complex apps top to bottom, just like any modern scripting language.

> Interestingly, Tcl was parsed the same way all the way up until Tcl 8.0 introduced a bytecode system in 1997. Each line was parsed right before execution with no separate parsing stage--your code could crash in the middle of executing from a syntax error.

Fun fact: most modern JavaScript engines in browsers work this way today, though at a different level of granularity. Parsing slows down application startup, so many JS engines don't parse a function body until it's first called. This means you can have a syntax error in a function body and won't know if it's never used.

That's pretty neat. Clearly some level of parsing needs to happen before run time, or else it couldn't even balance braces to know where the function body ends. So it must be that it parses the function body just enough to figure out where it starts and ends, then does a complete parse at runtime (probably building off the results from the first stage).

> or else it couldn't even balance braces to know where the function body ends

That's literally all it does. It tokenizes and counts braces.

I used to work with John and founded a company with him.

Whatever he believed he would have convinced you he was right :-)

Reply on news.ycombinator.com