Function form of keywords

This is going in here because it could either be a bug, an undocumented feature, I don't know what this is. Mariominer (Zee on Miiverse) posted this thread, stating he found a functional form of USE that returns an empty string. I was curious, so I tested. Turns out, it returns nothing at all! It acts the same way as USE with the exception that you write it as a function. You can even leave it alone on its own line and it works (but no OUT form exists.) Tried it on EXEC, it's the same way! Even PRINT, except that it can only accept one expression (no ; or , for you.) This hearkens to the functional form of VAR, which isn't so much a function as it is an alternate way to access a variable. Try all this and it works exactly as expected.

PRINT(20)
USE(1)
EXEC(1)

All of these instructions are marked as keywords in the syntax highlighting. So this leads me to believe that all keywords can be called like such, and may even have alternate features. Needs investigation.

Are you sure it's not just assuming that (1) Is just the number 1 in parentheses? EDIT: it is. PRINT() doesn't work. So these aren't functions, just statements where the argument is enclosed in parentheses, like in PRINT(x+1)*8

Damn, 12, I would never have thought of that.

Edit: I wouldn't have thought of passing a statement to USE or EXEC. I guess that's how you'd make a very short menu.

Well uh... I can explain. When I was testing, I tried PRINT USE(1) and it worked. It looked as if PRINT took USE as an argument. But this was the compiler playing tricks on me! It actually turned into this:

PRINT
USE(1)

Now, to understand my confusion you have to know this. When I was golfing some code one time, I encountered behavior when the parser attempted to pass an instruction as an argument. Take the statement VSYNC GCLS #WHITE for example. The parser turns it into this:

VSYNC GCLS
#WHITE

...and in the process it creates a syntax error! It weirdly assumes GCLS is a variable name, I guess. So the parser can distinguish a keyword from an argument, but it cannot tell statements apart from arguments. Wacky parser antics caused this thread.

Indeed. GCLS=3 is a valid assignment, and a subsequent PRINT GCLS will print 3. USE=7, on the other hand, is an Syntax error.

Put ?EXEC(X) where X is the slot the program is in. It prints indefinite newlines. After further testing trying different values of X, it seems to just execute the slot defined within parenthesis and output a single newline.

Put ?EXEC(X) where X is the slot the program is in. It prints indefinite newlines. After further testing trying different values of X, it seems to just execute the slot defined within parenthesis and output a single newline.

This is a simple one. The program gets interpreted as: first, the command ?, which prints a blank line second, the command EXEC(X), which runs the program again. The 'bug' here is that you can have two commands on the same line, without a command separator.

Indeed. GCLS=3 is a valid assignment, and a subsequent PRINT GCLS will print 3. USE=7, on the other hand, is an Syntax error.

It seems that any statement assigned a value will accept that value (OPTION, SPCLIP, STR$, etc). The type of value accepted (string, int, real) must match the suffix of the function (so STR$ must accept a string, but TALK must accept a number). Keywords do not follow this pattern (so you can't assign 2 to INC).

Indeed. GCLS=3 is a valid assignment, and a subsequent PRINT GCLS will print 3. USE=7, on the other hand, is an Syntax error.

It seems that any statement assigned a value will accept that value (OPTION, SPCLIP, STR$, etc). The type of value accepted (string, int, real) must match the suffix of the function (so STR$ must accept a string, but TALK must accept a number). Keywords do not follow this pattern (so you can't assign 2 to INC).

And what is your definition of a 'keyword', that TALK is not a keyword?

My definition of a keyword is what SB defines a keyword in the options menu.

Same here. I define keyword/statement based on the syntax highlighting. They do indeed appear syntactically distinct based on my info above. Persson: in your example the code is parsed as this:

?
EXEC(0)

As for passing statements, the issue is simply that statement names (GCLS, VSYNC and the like) aren't reserved for variables, so you can use them as variable names. Nothing too crazy here.

A keyword is anything that smilebasic interprets, other than variables. A function is a keyword that returns a value: STR$(number) A statement is a keyword that doesn't RETURN a value PRINT TOUCH OUT <tchst>,<tchx>,<tchy>

A keyword is anything that smilebasic interprets, other than variables. A function is a keyword that returns a value: STR$(number) A statement is a keyword that doesn't RETURN a value PRINT TOUCH OUT <tchst>,<tchx>,<tchy>

Not quite. The syntax highlighting has two specific categories: keyword and statement. Not all statements are functions and not all keywords are commands.

A keyword is anything that smilebasic interprets, other than variables. A function is a keyword that returns a value: STR$(number) A statement is a keyword that doesn't RETURN a value PRINT TOUCH OUT <tchst>,<tchx>,<tchy>

Not quite. The syntax highlighting has two specific categories: keyword and statement. Not all statements are functions and not all keywords are commands.

Every community has its own definitions... So with smilebasic it's command > keyword, statement Rather than what I'm used to: keyword > statement, function