?SPCOL(1)does not produce a syntax error. Neither does
?SPCOL(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21)I haven't checked the semantics.
Does SPCOL() with other amounts of arguments work?I checked one parameter, two,... all the way up to 21, when I stopped. None of them gave an error. I don't know what the upper limit is.
It seems, if the first parameter has not been SPSET, the function gives Illegal function call. None of the other parameters need to be 'set' sprite numbers, though. So far, I have only seen the value 0 returned by this function. I haven't really been testing it, though.Try:
SPSET 0,0 SPCOL 0 ?SPCOL(0)I'm guessing that it's only meant to allow 1 paramater, and SPCOL(1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21) being allowed is a bug. Does (1,2,3) evaluate to anything? if it does, then this might be caused by the same issue as USE(1)
Try:I get 0.SPSET 0,0 SPCOL 0 ?SPCOL(0)
Does (1,2,3) evaluate to anything? if it does, then this might be caused by the same issue as USE(1)PRINT (1,2,3) gives a Syntax error, strongly suggesting that (1,2,3) is not a value.
SPCOL() might be something that was partially removed or unfinished, but left in by mistake.Try:I get 0.SPSET 0,0 SPCOL 0 ?SPCOL(0)Does (1,2,3) evaluate to anything? if it does, then this might be caused by the same issue as USE(1)PRINT (1,2,3) gives a Syntax error, strongly suggesting that (1,2,3) is not a value.
I wonder if something like this could be used to easily fill arrays...I doubt it, the native array the native code MIGHT get isn't anywhere near us. I'm thinking like in JavaScript how your argument list can be any length. If it's too short you get undefined variables. If it's too long, they're ignored. (even less likely now) Code that does the same thing:
function SPCOL() {
VAR mgmt = arguments[0];
...
IF (arguments.length>2) {
Var scale = arguments[1]
...
Return things,things,things
} Elseif (arguments.length>1) {
...
}
...
}
The built-in might be using an args array (I wonder if it's not C...)Unless SmileBasic is running in an interpreter, the form of the arguments to a SmileBasic function is entirely unrelated to the form of the arguments used in the implementation language. I don't think it is running in a C interpreter.
It could also be the weird stack behavior that IAmAPersson thought he had, where the function will just take the right number of args off the stack, so this is implicitly calling form 4.More details please? EDIT: I see some of your details. But, that's not consistent with Syntax errors being thrown by program statements that don't even get executed.
I wonder if something like this could be used to easily fill arrays...Easier than FILL?
The way I see it, when you pass an argument list, you check for safety in the interpreter. I would build a list to check the length against the defined DEF's. That list can then be evaluated and pushed to the interpreter stack, or could be passed directly to a builtin function. I doubt SmileBasic just starts pushing the stack without some pre-checking, but hey it might.The built-in might be using an args array (I wonder if it's not C...)Unless SmileBasic is running in an interpreter, the form of the arguments to a SmileBasic function is entirely unrelated to the form of the arguments used in the implementation language.
If it is just throwing the arguments onto the stack, I imagine it counts and function calls have a precondition that throws an error when the counter is higher than the number expected. It could be something as simple as a programmer putting * for that limit (weird because its probably compiled) or a bug in how it counts. Edit: clarity because I'm just spitballingIt could also be the weird stack behavior that IAmAPersson thought he had, where the function will just take the right number of args off the stack, so this is implicitly calling form 4.More details please? EDIT: I see some of your details. But, that's not consistent with Syntax errors being thrown by program statements that don't even get executed.
