The following text was written by George Limpert:
Anyone who remembers coding in TI-BASIC on the TI-81 or TI-85 and has then has coded
for a more modern calculator knows the language has made great strides. Many of these
changes have been influenced by the collection of nerds and gamers we affectionately refer
to as the TI community. When TI created their original graphing calculator models, they
never envisioned they would be used for the purposes we have found for them. A large
portion of the changes to the language reflect the ideas of students over a decade ago who
envisioned their calculators entertaining them during boring lectures. Despite the many
changes to TI-BASIC, the language is still looked upon by the best game programmers as
inadequate at best.
The complaint of many programmers about TI-BASIC is its speed, or the lack thereof.
Unfortunately this issue is unlikely to be addressed anytime soon. When TI designed the
language, they envisioned a way of adding new math functionality to the calculator, but
with safeguards in place to prevent harmful behavior by programs. Speed of program
execution is nice but doesn't appear to have been one of TI's primary objectives when
creating the language.
Some people will suggest any serious programming ought to be done in assembly language.
Compared with programming in TI-BASIC, it's like going hunting with a rifle instead of a
pocket knife; it's faster, more powerful, and there's nothing to stop you from aiming that
rifle squarely at your foot. If you make an error programming in TI-BASIC, you get an
error message awaiting you to press a key. A mistake programming in assembly might give
you a sudden boost of free RAM in exchange for your valued programs, equations, and notes.
It's probably best to do serious game programming in assembly, but what about other types
of programs?
Not too long ago, a fellow with a fine idea for calculator programming visited the
flagship IRC channel for discussing TI calculators. Instead of compiling TI-BASIC programs
so they run faster, he proposed replacing the language altogether. While he was met with
ridicule, the idea is worthy of further discussion.
Last semester, I took a course on data compression techniques. One project assigned was
to implement a Huffman encoder and decoder in C or Java. The discussion in class about
Huffman coding went in one ear and out the other. Instead of struggling with C, I decided
to implement the project first on my TI-89 because I expected TI-BASIC to be simpler.
After about five minutes into coding, however, I hit a roadblock; there's no easy way to
implement any sort of trees. Sure, it's possible, but to many programmers it's not obvious
how to create or manipulate trees. The solution is to represent each node as a list; the
first element is the value and the second and third elements are the names of child nodes
within the binary tree. The child nodes are then accessed using a wonderful feature of the
language known as indirection. On the TI-83 line of calculators, however, indirection
isn't possible, and one would have to use a matrix, instead. Manipulating a matrix is slow
and makes the programming involved even more complicated.
A tree is one of the fundamental techniques used in programming. It's applicable to
many algorithms including searches and sorts. Unfortunately it can't easily be done within
TI-BASIC.
This discussion also addresses another major limitation of TI-BASIC. What if, instead
of storing the name of a child node, I want to store another data structure, such as a
list, in one of those spots? The answer, of course, is it's not possible. One might ask
why anyone would want to do this. Consider, for example, if a programming task involved
pushing an integer and a list to a stack. While no such task readily comes to mind, it's a
reasonable proposition. Stacks are another fundamental technique of programming. And, of
course, complex data structures alone are useful at times.
There are many other such examples of why TI-BASIC is inadequate. Even if it will never
be a fast language, simple programming techniques in the language ought to be exactly that
-- simple. These limitations make TI-BASIC useless to many applications that are not at
all related to gaming.
Programming in assembly can be difficult and dangerous to your data. It also usually
requires a computer, a link cable, and a lot of patience. If that's not the best option
and TI-BASIC is inadequate, maybe another programming language isn't so absurd of an idea
after all.
The obvious question then becomes what features should such a language have. If a
language is to truly replace TI-BASIC, it ought to have all the features that TI-BASIC
currently has with some additions to fix the limitations with TI-BASIC. It's likely a
replacement for TI-BASIC would need to be interpreted instead of compiled. One might
assume that if we're creating a new interpreted language that has more features than
TI-BASIC that it would be even slower. This is not necessarily the case.
The architecture of compilers and interpreters are very similar. The first step in
either is referred to as a lexical scanner. This scans through the program text for
keywords and symbols. The output generated is a series of tokens which represent the text
of the original program. TI-BASIC does this as well; on some calculators, programs are
always represented as tokens, but on others you will notice a delay when running a program
for the first time due to this conversion. The next step of a compiler or interpreter is a
parser. This deals with the syntax of the language, converting the string of tokens to a
tree structure. A tree in an accurate representation of how a language is actually
evaluated. Following this step is semantic analysis. A statement in a language may be
syntactically correct but still make no sense to the compiler or interpreter. At this
step, actions such as checking type and scope of variables are performed. At this point,
compilers and interpreters diverge. An interpreter will evaluate the parse tree and
execute the statements while a compiler will output another language such as assembly
language or machine code.
This discussion on the architecture of interpreters is relevant because the
implementation of TI-BASIC is not necessarily the most efficient scheme. Most likely,
TI-BASIC stores programs merely as a stream of tokens because of the space required to
store a representation of a parse tree. A parse tree, however, can be converted back to
plain text just as the stream of tokens can. If parsing is only done once instead of being
done constantly during execution, greater speed can be realized. One need not stop after
parsing, however. Much of the semantic analysis step can also be performed at this time
without modifying the parse tree. One may view this as a trade-off between program size
and execution speed, but it need not be the case. A parse tree, when outputted to a file,
can be compressed and then uncompressed at runtime, which may gain back some or all of the
space lost to representing the program as a parse tree.
Another major change to such a new language is in the area of variables. There is no
method within TI-BASIC to store a reference to another variable. Therefore any reference
variables will necessarily be local to the interpreted program. Such a language, however,
would still need to provide easy access to variables from TI-BASIC. This means that any
variables that are to use the additional features of this language will need to be
declared within the program. If this is the case, it allows for a few other enhancements
to the language. One potential enhancement is the concept of aggregate data types.
Dealing with variables is a major slow point of TI-BASIC. The language on some
calculators provides two very useful features for programmers -- dynamic types and dynamic
resizing of variables. Dynamic types mean that if I have an variable currently storing an
integer and I choose to store a string it it, the variable becomes a string variable.
Dynamic resizing of variables means that the space used to store a variable is
automatically expanded or contracted depending on how much space is needed to store the
data. While these are very useful enhancements, they are also slow. A new language could
make these features optional to programmers, providing an additional speed boost.
In spite of these and other possible enhancements, some tasks are better suited for
assembly language. Furthermore, programmers shouldn't have to reinvent the wheel every
time they write a program. PHP had a good idea when it allowed modules to be added to the
interpreter that extend the functionality of the language. While a new calculator language
may be at the core a replacement for TI-BASIC, the ability to extend the language through
modules instead of writing a new interpreter makes the language far more powerful than it
would be otherwise.
TI-BASIC is a fine language suitable for many tasks. Assembly has many advantages over
TI-BASIC and has many uses as well. There are, however, many programming tasks that for
one reason are another are not suited well to either language. A replacement for TI-BASIC,
if sufficiently enhanced, can make TI calculators a far more powerful tool. The question
of a new programming language shouldn't be a question of if but of how and what.
