What Tcl Is, and What It Was Built For

Part I · Module 1 · Chapter 1.1 · What Tcl Is, and What It Was Built For

1. The Question This Chapter Answers

If you have written C, Python, or SystemVerilog, you have a working theory of what a programming language is: a grammar with keywords and operators, plus a library of functions you can call. if is part of the language. + is part of the language. printf is part of the library.

Tcl does not divide the world that way, and almost every difficulty newcomers have with Tcl traces back to carrying the wrong division in. So before any syntax, we need the right one.

Two sentences, which the rest of this chapter earns:

• Tcl's grammar is one rule: a command, followed by its words.
• Almost everything else is a command — including if, including arithmetic, including the thing that prints.

2. The One Rule

A line of Tcl is a command name followed by words separated by spaces:

puts "hello from Tcl"

There are two words here. The first, puts, names the command to run. The second is the text it should write out. Tcl's job on seeing this line is narrow: work out the words, find the command named by the first one, and hand it the rest.

That is the shape of every line of Tcl you will ever write:

puts "starting"
set greeting "good morning"
string length "hello"
file exists report.txt

Four commands — puts, set, string, file — each handed some words. No semicolons required at the end, no parentheses around arguments, no commas between them. Spaces separate words; a line break ends the command.

3. What the Interpreter Actually Does

Tcl is a language, but it is also a program that reads that language. Keeping those two meanings apart is worth doing early, because both get called "Tcl" in conversation.

The program is called an interpreter. You give it text; it works through that text command by command, and for each one it finds the implementation and runs it. The language itself contributes the rule for splitting a line into words and locating the command. The work — writing output, comparing strings, opening files — happens inside the commands.

Read that right-hand box as the interesting one. In most languages the middle box is large and the right-hand box is a library you may or may not use. In Tcl the middle box is deliberately tiny, and the right-hand box is where the language lives.

4. How Small Is "Small"?

You can ask the interpreter directly. info commands returns the list of commands it currently knows, and llength counts how many things are in a list:

puts "built-in commands: [llength [info commands]]"

built-in commands: 92

Ninety-two commands, on the interpreter this was run against. The exact number varies between Tcl releases, so treat it as an order of magnitude rather than a fact to memorise — run the line yourself and see what your interpreter reports.

The number worth comparing it against is the count of things that are not commands, which is roughly a dozen pieces of punctuation. That ratio is the design.

5. The Proof: if Is a Command

This is the claim that sounds like wordplay until you watch it happen. In Tcl, if is not a keyword that the language understands. It is a command named if, sitting in the same table as puts, that happens to take a condition and a body.

Ask the interpreter whether it knows a command by that name:

puts [info commands if]
puts [info commands puts]
puts [info commands while]

if
puts
while

All three are commands. info commands found them the same way it found puts.

Now the demonstration. rename moves a command to a different name, and proc defines a new command. So we can push Tcl's if out of the way and put our own in its place:

rename if original_if
proc if {args} {
    puts "my own if was called"
}

if {1} {puts "this body never runs"}

my own if was called

The if on the last line called our command. The body we passed it was never run, because our replacement ignores its arguments and prints a message instead.

Stop and consider what that output means. You cannot do this to if in C, Python, or SystemVerilog, because in those languages if is part of the grammar — it is handled before any function lookup happens. In Tcl there is no grammar for if to be part of. It is a name in a table, and names in tables can be changed.

6. Why Anyone Designed It This Way

A language with almost no grammar has one unusual property: a host program can add to it without changing it.

Suppose you are writing a large engineering application and you want users to automate it. You could invent a configuration format, which will grow conditionals and loops until it is a bad programming language. You could embed a full language, and inherit its grammar, its parser, and its assumptions. Or you could embed Tcl, register your own commands into that command table beside puts and if, and get a complete language in which your application's own operations are indistinguishable from built-ins.

That third option is why Tcl shows up where it does. Its original design goal was to be the embedded control language that applications share instead of each inventing their own.

Semiconductor design tools took this up comprehensively, which is why a chip designer or verification engineer runs into Tcl constantly — synthesis, timing analysis, and simulation tools are commonly driven by it. That is motivation for learning Tcl, not a prerequisite for it. Nothing in Part I will ask you to know anything about chip design. Chapter 1.3 explains the embedding mechanism properly, and Part II is where tool-specific commands belong.

7. What This Chapter Deliberately Did Not Explain

You have probably noticed unexplained punctuation: the quotes around text, the square brackets in [info commands], the braces in {1} and around the proc body.

Those are Tcl's substitution and grouping rules, and they are the whole subject of Module 2. They are not an appendix to the language — they are the mechanism that makes a language with one grammatical rule actually workable, and they deserve a module rather than a paragraph.

What matters here is only that they exist and that they are about how a line becomes words. When you reach Module 2, you will find it answering a question you already have.

8. The Idea in One Line

If you remember nothing else from this chapter:

Tcl is a command dispatcher with a very thin grammar. When something in Tcl surprises you, ask "which command is this, and what words is it getting?"

That question resolves a startling proportion of Tcl confusion, including most of what Module 2 covers formally.

9. Exercises

Exercise 1 — count your own commands. Put the count.tcl line from §4 in a file and run it. What number does your interpreter report? Chapter 1.6 covers running a file in full, so if you cannot run it yet, come back to this after 1.6.

Exercise 2 — identify the words. For each line below, write down how many words it has and which one names the command. Do not run them yet.

puts "two words here"
set count 0
string length "hello"

The middle line has three words, and the answer for the first line is two, not four — the quotes group text into one word. If that surprised you, you have found exactly what Module 2 is for.

Exercise 3 — predict the failure. Our replacement if in §5 took args and ignored it. Predict what puts [info commands if] would print after that rename ran, and why. Then check by adding the line to the end of replace-if.tcl.

Exercise 4 — the honest answer. Without re-reading, write one sentence explaining to a colleague why if being a command is not a trivia fact. If the sentence does not mention Tcl's grammar being small, read §5 and §6 again.

10. Summary

• Tcl's grammar is one rule: a command name followed by words, separated by spaces, ended by a line break.
• The interpreter's own job is narrow — split into words, look up the first word, dispatch. The work happens inside commands.
• Things that are keywords elsewhere are commands here. if can be renamed and replaced, which is the proof rather than the assertion.
• The language ships around ninety commands. Ask yours with llength [info commands] rather than trusting a number.
• The small grammar is why Tcl is embeddable: a host application registers its own commands into the same table, and they become part of the language the user types.
• Tcl's commands and a host tool's commands look identical and are not. Part I is only the first kind.
• Quotes, brackets, and braces are real and unexplained so far. They are Module 2, and they are the mechanism that makes the one-rule grammar work.

The next chapter deals with a question that follows immediately from "the interpreter reads your text and runs it": what people mean when they call Tcl a scripting language, and whether that is a real category.