This isn't a bug. It is correct behavior. I happen to have my 3DS nearby so let's try some things.
A = "HELLO"
Result: type mismatch in 1:1. A is a number, A$ would be a string. You are trying to put a string in a number variable. To fix it we write.
A$ = "HELLO"
Result: OK
Let's try another:
PRINT "<" + A$ + ">"
Result: <>
I neither case did we declare the variable. SmileBasic allocated it for us. It did that when parsing your code and saw PRINT A, but when you got to VAR, it already had a variable called A. So you got a redefinition error. You should always declare variables before they are used.
Option Strict requires you declare all variables so when turned on tells you that you have an undeclared variable on the print A line. But, consider this code.
SPELL$ = "MAGIC"
PRINT "SPELL: " + SPEIL$
Expected result: SPELL: MAGIC
Actual result: SPELL:
Why, because on line two I misspelled SPELL$ as SPEIL$. We ended up with two variables instead of one and SmileBasic gave us no indication of the type-o. Imagine trying to track down an error like that in thousands of lines of code. What happens if we add OPTION STRICT to the top of the code? An undefined variable error is generated and it tells you where the type-o is. This is extremely valuable once you write any significant amount of code.
Now onto the ugly elephant in the room, GOSUB, stop using GOTO/GOSUB. If you need help using functions I am happy to help. I have gone over it at length, so I will spare you a repeat. You probably didn't know that GOSUB was a problem in your code but it is.
When you use functions, any variables declared within the function are local to it and not visible globally. Using GOSUB has the sinister side effect of requiring you to use only global variables. Without intending to, one routine can accidentally stomp over top of another routines data.
Consider two GOSUB subroutines the first has a for loop that uses variable I to go from 1 to 5 and calls the second via GOSUB each time through the loop. The second GOSUB uses I as a FOR loop counter going from 1 to 3 then returns. Result is that the first GOSUB loops forever due to the second editing its counter. Again miserable to debug for code of any scale. If they had local variables in a function it would have worked as intended.
GOSUB @A
END
@A
FOR I = 1 TO 5
PRINT "@A: "; I
GOSUB @B
NEXT I
RETURN
@B
FOR I = 1 TO 3
PRINT "@B: "; I
NEXT I
RETURN
Versus:
A
END
DEF A
VAR I
FOR I = 1 TO 5
PRINT "A: "; I
B
NEXT I
END
DEF B
VAR I
FOR I = 1 TO 3
PRINT "B: "; I
NEXT I
END
The second works as intended, the first doesn't. The second is also more reusable. You can copy and paste it into future code without bringing along a mess of global variables that may already be in use for something else.
If you had used functions your second declaration of A would have been local. It would have run without crashing but not as intended. However the detail of it being in a function probably would have prompted you to move the variable definition to the global scope where it belonged, then it would have worked as intended.
I think you want something like this:
OPTION STRICT
VAR A$
INI
MAIN
END
DEF MAIN
WHILE (BUTTON() AND #X) == 0
PRINT A$
WEND
END
DEF INI
A$ = "It runs ; let us sell it !"
END
The differences are minor but pay off.
Lessons:
- OPTION STRICT is awesome, use it
- Declare all variables. Also declare them at the top of the code/function before use
- String variables should end with a $
- Gosub is terrible
- Local variables reduce bugs and improve code reuse/portability
