Unassigned Variables: X = 0? (Small Basic Featured Thread)

Small Basic handles unassigned variables as equal to zero. The idea is that variables are always available. Let's look at this thread from the Small Basic Forum:

https://social.msdn.microsoft.com/Forums/en-US/9aa087df-c0da-418b-95ac-ed399b2fb9e5/initialization-issue 

SeyfiD started the thread:

I was about to give an introductory programming course using Small Basic. I encountered following issue while playing with it (v1.1 on Windows 8.1 x64):

the single liner below does not compile and display the error "the variable x is used but its value is not assigned", which is expected.

y = x+1

the following single liner however compiles w/o error, and automagically assigns 0 as the initial value for x:

x = x+1

is this expected? if yes, how do you explain it?

Liam McSherry answered:

Hi SeyfiD,

This does look like a bug, and probably stems from how Small Basic's variables work.

All variables are always available, even if they were declared in a subroutine/If-Then/loop and haven't been assigned to yet. For example, this will print '-5' to the text window:

TextWindow.WriteLine(x -5)Sub Test x =10 EndSub

As all variables are always available, they contain the "uninitialised" value up until something assigns to them. Small Basic doesn't have concrete data types (like strings and integers and decimals), but has a single data type ("Primitive") that handles cases for all three situations. This means that the uninitialised value varies depending on how you use the variable: use it as a string, uninitialised is empty string (""); use it as an integer, the value is 0; and use it as a decimal, the value is 0.0.

In the case of your code, the compiler is probably recognising that 'x' is assigned to, so it creates 'x' without checking what value it is assigned. The compiler has to find all variables first because you can use a variable "before" (lexicographically) you assign to it. If it didn't, it wouldn't be able to recognise uses of variables before they're assigned to. Doing it this way was likely done to simplify the compiler.

After the compiler's found all the variables, it probably then goes through the program again, checking to make sure that all variable references are correct. Because it constructed the list of variables separately, it doesn't recognise that the assignment in your example should be invalid, and instead allows it. When the code is executed, 'x' is treated as an integer (because it's being added to '1', another integer) and the uninitialised value '0' is used in the addition.

Summary:

• Bug? Yes.
• Serious? Not particularly.
• Fixable? Yes, but it would require a compiler update and would be a breaking change (older programs may become broken).

I imagine, if reported, the Small Basic development team would consider fixing it, but it's not a show-stopper or otherwise high-priority bug, so the fix would likely be slow in coming.

Nonki Takahashi helped clarify:

There is the following description in the FAQ of Small Basic:

And the discussion still continues! You can join it here:

https://social.msdn.microsoft.com/Forums/en-US/9aa087df-c0da-418b-95ac-ed399b2fb9e5/initialization-issue 

Small and Basically yours,

   - Ninja Ed