Why do variable names in BASIC need type suffixes?

Question

The BASIC I'm most familiar with is Atari BASIC since I had an Atari 800 way back when.

The Atari BASIC Source Book includes details about how Atari BASIC maintains variables. There is a Variable Name Table that essentially assigns an index number to each variable name. The interpreter uses the index to get the variable value from the Variable Value Table.

The Variable Value Table includes:

• The type of the variable
• The index number of the variable
• 6 additional bytes of data that vary depending on the type of the variable

My question is: Since the variable value includes the type, at least in Atari BASIC, why does the programmer need to also include the type in the name of the variable? In other words, why can't we just do LET X="HELLO" without making it X$? It knows the right-hand side of the assignment is a string, so it can just assign a string to X. And if the program later does LET X=1 then the value could then be an integer.

My thoughts:

• Possibly this was important when variable names were limited to 1 letter since that would give 26 numeric variables and 26 string variables.
• Maybe some BASICs have separate data structures for string and numeric variables and the suffix tells the interpreter which one to use.
• BASIC could be doing type checking when parsing the line, avoiding the need to check types at runtime.

Answer 1

To add to the "because it's BASIC" answers: BASIC came from the Dartmouth Timesharing System (DTSS) in the 1960s. Other implementations need to follow basic BASIC standards.

In 1964, the variables A and A() -- i.e., scalar and array -- were considered to be different. BASIC, Oct 1964, page 36. There were no string variables.

By 1968, string variables, and string arrays, had been added. These had names ending in a dollar sign, thus A$ and A$(). BASIC, Jan 1968, page 63.

So that's the original BASIC. And that's why every other BASIC has to follow suit.

Why? Because of the 'B' in BASIC - "beginner's". The designers, who were very capable but still feeling their way at this time, probably did not want to burden their users with either type declarations such as were found in ALGOL, nor with dynamic typing such as was found in LISP. A fixed name format seems clear.

And, note, DTSS BASIC was a compiled language, not an interpreted language. That too may colour some decisions, for example maybe you don't want to need runtime type checking on the validity of

100 LET X = Y + 1

which presumably is meaningless if Y is string-valued.

Answer 2

TL;DR:

Most straight answer: Because it's BASIC

A trailing '$'-sign is the syntax BASIC defined when adding strings.

Also, the suffix is not only a type marker, but part of the name. In BASIC A and A$ are two different variables. This is not a bug but a feature. The type is needed to distinguish them.

The BASIC language is defined to work that way. Changing this would make it a different language/add incompatibilities (*1). Much the same way that C requires parentheses around function parameters, despite that it would have been possible to go without.

---

It's an Atari

... how Atari BASIC maintains variables. There is a Variable Name Table that essentially assigns an index number to each variable name.

I guess that's a point where much of the confusion is originated. Atari BASIC is a very special implementation; the Variable Name Table is a prime oddity here. Atari BASIC keeps a static 128 entry table of all variables, using a unique indexing system for access. More so, this table is even static across many operations like editing - unlike variable handling in many other BASIC (*2).

But even Atari BASIC follows the rules of the BASIC language and handles A and A$ as different variables. Simply try this:

10 A=1
20 DIM A$(3) : REM Special case only needed for Atari BASIC
30 A$="ABC"
40 PRINT A,A$

Every BASIC compatible with its forefathers will print

RUN
1       ABC

READY

This Example works only because these are two variables, different by type and name and is an inherent feature of BASIC.

That table and its behaviour is Atari specific, not part of any generic BASIC definition. So the question might be not about BASIC but rather why Atari BASIC didn't diverge and automated type detection. The answer could be that, beside a more complex parser, less readability and unclear situations it came down to avoiding incompatibility with BASIC as a language.

It's a Language Predating Atari's Implementation

My question is: Since the variable value includes the type, why does the programmer need to also include the type in the name of the variable?

Because it's part of the name? Even with Atari BASIC, the '$'-Suffix is stored in the name entry and Atari BASIC does distinguish between A and A$.

Maybe Atari could have left out the variable type, but then their programs would be incompatible to BASIC - i.e. be only a BASIC-like language.

Not to mention that in this case variable declaration would become mandatory to the tell the interpreter ahead of time which type a variable should have. A feature BASIC avoided on purpose for simplicity (unless one wants to increase complexity with sum types).

In other words, why can't we just do LET X="HELLO" without making it X$?

Because then the compiler/interpreter would not know what type X is supposed to be.

It knows the right-hand side of the assignment is a string, so it can just assign a string to X.

No, it doesn't, as it works simply left to right. No look ahead and no backtracking. BASIC is intended to be a simple language. For usage as well for implementation.

And if the program later does LET X=1 then the value could then be an integer.

Beside that integers are a later addition (and the fact that there is no look ahead), how to tell the compiler/interpreter that it's an integer, not a float?

Also, wouldn't that redefine the variable from string to integer? Polymorphism isn't a thing in BASIC, it's of strict type.

It's about Teaching

Beside simplicity of compiler/interpreter design, it all comes down to the fact that BASIC is intended to be basic. BASIC is a language meant for teaching people who never ever touched a computer before, nor seen one in their whole life (*3). It is about introducing concepts that are completely alien to students in the 1960s.

Teaching starts with introducing variables for numbers and giving them names. The idea that computers divide numbers in classes, like float or integer, is still to be learned way later. Then strings are added and marked accordingly and way later integers may be added and so on.

Adding variable definition ahead of usage might seem like natural to experienced users - and the way even back then 'professional' languages used - but it's an additional hurdle in the process of learning. One BASIC has avoided by usage without declaration - which implies that each occurrence had to be type qualified.

And it's about Era

When trying to understand a language of the past, it helps to look at their intention, and to remember that 1961 is not 2021. And Computers in the 60s are worlds apart from today's machinery.

---

From the thoughts section:

Maybe some BASICs have separate data structures for string and numeric variables and the suffix tells the interpreter which one to use.

What data structure is used is implementation, not language definition, isn't it? Also, yes, other interpreters use other structures - but all used on micro computers were created way after BASIC as a language was defined.

BASIC could be doing type checking when parsing the line, avoiding the need to check types at runtime.

That is exactly what BASIC does - just no look ahead. Also, parsing of a line is done, even in Atari BASIC only for syntactical correctness, to determine variable types, as the structures to be used do not exist at that moment in time.

Variable tables are build only at runtime.

---

*1 - Which Atari did anyway.

*2 - Introducing quite some unexpected trouble when not starting with NEW

*3 - Maybe except in flicks like Colossus :)

Answer 3

Akin to Raffzahn's answer, yes, because it's BASIC.

That said, later BASICs had DEFINT, DEFSTR, and such to set the types of variables upfront, so that you no longer had to use suffixes.

Similar to the IMPLICIT statement in FORTRAN.

Answer 4

Section 7.1 of the ANSI X3.60-1978/EMCA-55 Minimal BASIC Standard specifies that string variable names end in the "$" character.

That particular string variable naming specification allowed the Standard to be backwards compatible with the 1968 implementation of Dartmouth BASIC (and with DEC BASIC, et.al.).

So support for that type of string variable names is required. (whether or not any particular implementation could do otherwise, due to symbol tables or whatever...) There are hints on the web that specification compliance may even have been a government purchasing requirement.

And Shepardson Microsystems possibly didn't even start porting Atari Basic until after the Minimal Basic Standard was published in 1978.

Answer 5

Any answer to this question is going to be somewhat a matter of opinion, since there certainly are languages that are designed with dynamic typing, and BASIC could have been done that way. Unless someone comes up with a memoir or historical article explaining some of these design decisions, we won't really have a conclusive answer.

I disagree with the answers saying that Dartmouth BASIC worked a certain way, so later versions of the language had to follow that. There was no source code compatibility between different implementations of BASIC. Apple II BASIC was different from TRS-80 Level I BASIC, and so on. If you were typing in code from a book or magazine, part of the process was to make the appropriate changes for your own machine's dialect.

Some versions of BASIC only allowed one-character variable names, while by the era of consumer machines, most dialects allowed two-character names, such as AB or A7. This was doubtless a memory-saving and efficiency device. A two-letter variable name could be encoded into two bytes, and manipulated by putting it in a 16-bit register. This created an artificial shortage of variable names, especially if you wanted to find variable names that would be memorable. Worsening this shortage were two other factors: (1) there were no local variables, and (2) source code was normally all upper-case. Because of this shortage, it was a big win to be able to have an N$ for the user's name, and have that be different from N which was the number of something.

I don't think the issue was purely the simplicity of parsers. Actually, the parsing and polymorphism were pretty complicated. You can play around and observe this in an emulator, e.g. http://trsjs.48k.ca/

A%=3:B%=4:PRINT A%/B%

This outputs .75, which shows that operands could automatically be promoted from integer to floating point. (Although this design decision probably made the interpreter slower, it would definitely be preferable, for beginners, compared to having the result be zero.)

A%=1.9:PRINT A%

This outputs 1, showing a demotion from float to int.

It's certainly not true that the interpreter could look at the left hand of an assignment and know the types of all the operands on the right-hand side.

A$=CHR$(42)'RIGHT-HAND SIDE INVOLVES AN INTEGER BUT RESULTS IN A STRING

There is type checking:

A%="HELLO"'PRODUCES ?TM ERROR

Although functions like LEN and STR$ had suffixes that indicated their types, the binary operators were polymorphic.

A$="HELLO":B$=" WORLD":PRINT A$+B$

Note that although there was stuff like DEFINT, it was optional, and in general there were no type declarations as in languages like pascal. This was obviously a usability decision for beginners. Incorporating punctuation to show types is actually a pretty widespread idea, as in languages like the Unix shell, and Perl.

I would guess that it helped quite a bit in simplifying the parser and making it more efficient that it could always tell the types of operands on syntactic grounds. Suppose that BASIC had had dynamic typing. Then what does the following code do?

A=B+C

In a hypothetical dynamically typed BASIC interpreter, we would have to look at the type of B, look at the type of C, then determine whether they're both strings, both numeric, or one string and one numeric. Then we'd have to have three different branches: concatenate, add, or throw a type error. The performance of the language on these machines was horrible. They certainly didn't want to make design decisions that would make it even worse by adding more complication at run-time.

If there was a dynamically typed interpreter, it would also automatically add some complication to the run-time, which had to be small (e.g. 16K of ROM). We would need functions for converting from one type to another. We would also need some provision in the user interface for inspecting the type of a variable.

Answer 6

Firstly there is more than one way to assign a value to a variable. Eg input x, y Print x+y If the input is 4 and 2, should the interpreter return 6 or "42"? You need to be able to tell apart strings and numbers.

Secondly limited memory space was a major consideration back then. Strings usually reserved 256 bytes, whereas numbers required much fewer bytes. This is particularly an issue with arrays, eg if dim a(10,10) needlessly reserved 10 x 10 x 256 bytes (when all you wanted was numbers not strings), then that's 25,600 bytes consumed out of eg 65,536 bytes total memory. Reserving 256 bytes for just one string literally took away 0.4% of your total memory, and there's no need to tie up that much resource if the variable was just a number.

Answer 7

Symbol table space was the most likely culprit. Integers and floating point values were known sizes. Strings were problematic.

The interpreter (or P-code) had to keep track of all the variables and their contents. floating and integer types were easy to store, as they had a known size. strings were trickier and required additional information to store, such as the length of the string - some Basics required you to declare the size of the string before you could use them.

The run-time would have to look up the value of a variable in the symbol table before using it. Knowing if it was a string, integer, or floating point value makes the lookup easier.