Direct mode commands are parsed differently.

In Direct mode:

CLEAR:DIM A$[2]
PRINT A$[0]

generates "Subscript out of range", as if the array had not been declared at all.

In fact, everything after CLEAR is ignored. Just try typing something completely random and it won't even error.

welp, this is a bug if I've ever seen one!

It's a command exclusive to DIRECT mode anyway. It shouldn't even have any effect in the editor.

Huh? doesn't it clear all the variables from memory? sounds like a useful command to have at the top of your program (as was common practice in PTC)

It seems the interpreter is set to ignore any DIRECT mode-exclusive command and everything else that comes in the same line after it. So it's not really a bug, or maybe only a minor bug in the parsing process.

It seems the interpreter is set to ignore any DIRECT mode-exclusive command and everything else that comes in the same line after it. So it's not really a bug, or maybe only a minor bug in the parsing process.

The interpreter does not ignore DIRECT-mode-exclusive commands when it is in DIRECT mode. Also, using the DIRECT-mode-exclusive command PROJECT, commands that come in the same line after it are not ignored:

PROJECT "TEST1":PRINT "QWERTY"

will, assuming there is a project "TEST1", result in the current project getting changed to it, and, "QWERTY" getting PRINTed. When DIRECT-mode-exclusive commands are executed from program slots, they are not ignored, either. NEW, for example, will cause a Syntax Error. This is because, strangely, NEW is treated as a variable. In a program, you can write

NEW=7:PRINT NEW

and get 7. PRINT NEW also works in Direct mode, but not NEW=7, but VAR("NEW")=7 does, but VAR("PRINT")=10 does not. Minor or not, the issue described in the top post is a bug.

On the variable confusion: From the manual:

The following words cannot be used because they are reserved for variable and statement names: IF THEN ELSE ENDIF GOTO GOSUB RETURN ON FOR NEXT WHILE WEND REPEAT UNTIL BREAK CONTINUE DEF END VAR DIM AND OR XOR NOT DATA READ RESTORE PRINT INPUT LINPUT CALL TRUE FALSE SWAP OUT COMMON USE EXEC

Based on this, PRINT is reserved, so you can't set it - no VAR("PRINT"). NEW is not reserved, so you can set its value - yes VAR("NEW"). However, while in DIRECT mode the system is trying to interpret it as a DIRECT command instead of a variable. Within EDIT mode, you can set any of the DIRECT mode only commands as variables since they have no special meaning there. The main takeaway from this is to not use the DIRECT only commands as variables while in DIRECT mode. I doubt most people will actively try this, as they are clearly marked as instructions in the documentation. On the behavior of commands when combined: this can be see in Petit Computer as well - there are certain statements that can't be combined with colons and have to go on their own line (I ran into this a lot when trying to make a minifier for PC). I expect the same thing will happen in SmileBASIC as well.

They also forgot to make "MML" and "PI" reserved words.

They also forgot to make "MML" and "PI" reserved words.

I decided to look into this last night. Made a post about PI() on the Miiverse bug thread. I decided to look through every single autocomplete entry to see which ones had highlighting (thus, which ones were reserved) and I found two more unreserved keywords: TO and STEP. You can use them as names for anything without restriction, which is really bad. Also, REM is mysteriously missing from the autocomplete (not that we're losing anything as a result.) MML as a reserved name is a bit silly because it's just a hotword for the popup help. EDIT: Here is the Miiverse post I wrote about PI(). I have an addendum. You can create new commands with the name PI and they will work completely as expected, but new functions with the name of PI() are ignored as if they don't exist. Really weird.

Just occurred to me that ? doesn't have syntax highlighting either. It really should be highlighted as a keyword since it's just an alias of PRINT.

There are some other things that I think should have highlighting: operations: +,-,*,/,= -things like X=X+VX have NO highlighting at all... options: DEFINT, STRICT, MOTION, MIC, EXPAD Also: FOR F0R = T0 TO TO STEP STEP:NEXT lol

messed around with the line :FOR F0R = T0 TO TO STEP STEP:NEXT using for and to as var names. I didn't know you could pass a string to the var instruction. Is there an instruction that'll do the opposite? return a string representation of the passed var? anywho, some weird behavior I dont' know it it is that the var is never used, or the fact that it is the "TO" Keyword uncomment the '?TO line and it'll work, but only without OPTION STRICT.

VAR("TO")=0
FOR I = 0 TO 2
?I
'?TO
NEXT

https://vid.me/cGga 'edit slackersnail educated me a lil, think its cause var returns a reference, but to what? probably preprocessor saying TO never got used as a variable so there is no reference to return. I'm silly.

All (built in) function names (purple) can be used as variables All "option" keywords (STRICT, TOOL, DEFINT, TO, STEP. All have no highlighting.) can be used as variables. light blue keywords are reserved. EDIT: They had to go and make TO and STEP blue, which ruins all this. Oh well, you shouldn't use these as variable names either way.

I didn't know you could pass a string to the var instruction. Is there an instruction that'll do the opposite? return a string representation of the passed var

Yes, the the syntax is:

"VARNAME"

This advanced function will return the string "VARNAME". (sorry, just thought this was funny :P)