The following basic programs written in TCL will give you a general introduction to the TCL syntax:
aa - Tcl syntax isn't anything like C syntax. It's unlike the syntax of most other popular languages. It's supremely simple and straightforward. These basic programs serve mostly to show the absence of the kind of incantations that are required when programming in a language like C.
aa I think the Endekalogue provides a more useful introduction to Tcl syntax, though it's likely that only someone who is already familiar with Tcl's quoting and substitution rules -- and who isn't burdened by trying to see it in a C-like context -- will understand it easily. emj Exactly, which is why we need examples as well.
In this example, a file called hello.tcl contains the following text:
#! /bin/env tclsh puts "Hello world!" exit 0
To run this script:
tclsh hello.tcl
In the above example, it may be necessary to replace "tclsh" with "tclsh.exe", "tclkit", "tclkit.exe" or whatever your Tcl interpreter is called.
LES: calling 'exit' at the end of every script can be a good habit. Especially if you use Windows and/or ActiveTcl and have .tcl files associated with wish. Scripts run with wish won't exit (and/or return output) until you close them manually if there is no exit command.
Note that if you are on Unix, there's no requirement to end the file name in .tcl. However, by doing so, then on Windows, one can associate the tclkit with the file. And Unix users who use a GUI file manager can do the same thing. And MacOS X users can do the same thing. Thus, instructions can be written in a more cross-platform manner.
LV On Windows, the first line is probably not relevant until you start using Cygwin or some other Unix emulation on MS-DOS package. It is my understanding that the default command processor on Windows ignores the #! line anyways. So on Windows, you would either type:
tclkit.exe hellowworld.tcl
or you would go through whatever the steps are to associate tclkit as the program to use with files that end in .tcl.
Variables hold values (What sort of values? Any!) You read from a variable by putting a $ in front of its name, and you write to it using the set command. Variable names can be made up of almost any characters, but it is usually easiest to use just letters any numbers. The following is an example of various valid variable names:
set age 42 puts $age set Age 42 puts $Age set AGE 42 puts $AGE set "my age" 42 puts ${my age} set "My AGE" 42 puts ${My AGE} puts [set "My AGE"]
Variable names with whitespace characters in them need to have curly brackets around them for Tcl to understand them, or else Tcl would assume the variable name ends at the space or any other non-alphanumeric, non-underscore character.
Alternately, use the [set] command with only one argument to get the value of a variable. This is useful if the variable name is computed or contains special characters, especially close brace, that are difficult or impossible to use with normal $dollar sign notation. Quotes are used to force "My AGE" to be interpreted as a single argument even though it contains a space. Braces can also be used for this purpose, or you can put a backslash in front of each space to disable its word separation ability.
See Also
FW: stdin stands for Standard Input, and is where you can read input from with gets (get string). All programming languages support this sort of thing, including C. It means the channel to receive input from (there's also a stdout, and an stderr, which are places to write output and error messages to; puts writes to stdout by default). This is usually commands typed in the console, but a program can be for example invoked by another program, which sends it data.
puts "Please tell me your name." gets stdin Name puts "Hello, $Name!"
Ask a person his/her age. If it is under 20, reply: "you are a child or a teenager". If it is 20 or over, we reply: "you are an adult now".'''
puts "Hey dude, how old might you be?" gets stdin Age if {$Age < 18} { puts "You are a child or a teen-ager" } else { puts "You are an adult now" }
If the user entered something that wasn't a number, there would be an error, but that's a topic for another time.
RS: Alternatively, one could use the arithmetic if operator, replacing the last 5 lines with:
puts "You are [expr {$Age<20? {a child or a teen-ager}: {an adult now}}]"
In other languages, if and else might be considered "statements", but in Tcl, they are just commands. Tcl doesn't have a concept called "statement". Tcl features like the uplevel command makes it possible to design constructs that in other language, require additional concepts like "statement".
A more concise example of the same program:
puts "Hey dude, how old might you be?" gets stdin Age puts "You are [expr {$Age<20? {a child or a teen-ager}: {an adult now}}]"
In the following example, there are three possible conditions, rather than two:
puts "Hey dude, how old might you be?" gets stdin Age if {$Age < 12} { puts "You are a child" } elseif {$Age < 19} { puts "You are a teen" } else { puts "You are an adult now" }
The following isn't necessarily an example of good style, but it does work:
puts "Hey dude, how old might you be?" gets stdin Age puts "You are a[expr {$Age < 12 ? " child" : ($Age < 19 ? " teen" : "n adult now")}]"
You can use && and || in expressions to connect sub-expressions together. && should be read as "and" and || should be read as "or".
puts "Hey dude, how old might you be?" gets stdin Age if {$Age >= 0 && $Age <= 12} { puts "You are a child." } elseif {$Age >= 13 && $Age <= 19} { puts "You are a teen." } elseif {$Age > 19} { puts "You are an adult now." }
Another way to write the same program:
puts "Hey dude, how old might you be?" gets stdin Age if {$Age <= 12} { puts "You are a child." } elseif { $Age <=19 } { puts "You are a teen." } else { puts "You are an adult now." }
This seems to be a use case for the comb pattern:
puts "You are a(n) [comb $Age {child 13 teen 19 adult}]"
Just to show (off) that functional programming can be put to surprising uses all over the place. In Tcl, you can code like in C, but maybe you shouldn't...