Reply to Re: SEMICOLONS ARE THE SPAWN OF BEELZEBUB
If you don't have an account, just leave the password field blank.
This thread is a couple years old, but still a relevant topic, imo.
I humbly disagree with not needing semicolons, and brackets certainly are essential, especially if there is some "optional" code segments which precede mandatory segments.
Semicolons:
If I remember correctly, the parser looks for white space greater than 1 space, to indicate the end of a line. This explains why only 1 white space can exist between elements in an equation, for example.
i.e. &num == 1;
would fail at the '1' because it is a set value which cannot be changed or referenced as a variable.
&num == 1
is likely to fail, because the assignment isn't complete and the actual value of &num may not be properly defined, even if it seems to be, "sometimes".
At the same time, there are different flavors of whites pace; a space, hard space, CR, LF, CRLF, TAB... though these may appear to look the same in your favorite editor, they would each result in a different amount of spacing in a text.
Using a Semicolon indicates that the assignment is complete, and requires at least 1 white space to allow the parser to click to the next interval. Extra spaces following a semicolon are ignored.
i.e.
&num == 1; //A number
&num == 1; //A number
are identical to the parser.
I would suggest using semicolons, "at least" to end each assignment statement, as well as any statement which signifies the end of the script, or would relinquish control back to the que. The semicolon would also serve as a return point for when the script gets it's next turn in the cycle. imho, it would be less likely to fail if you used a semicolon to complete a statement that maybe did not require one, than to fail because you omitted one that was required. Also, in Seth's original notes he said, that including multiple assignments on one line would likely work fine, but there were occasions the parser didn't read them right, and suggested to put one per line just to be sure. There are examples in his own scripts that assign 2 on the same line, though only a few times this occurs.
i.e.
&strength = 3; &defense = 1;
"should" work, though more complex assignements that deal with references may be quirky.
sp_seq(&mouse, 0); sp_brain(&mouse, 13); sp_pseq(&mouse,10);
May be a challenge and should be coded as,
sp_seq(&mouse, 0);
sp_brain(&mouse, 13);
sp_pseq(&mouse,10);
Another point worth mentioning, when using compress to make .D files, it uses a pairing system to accomplish much of it's compression. White space within quotes will be packed as a literal string counting how many spaces there are, outside a string it is likely to choose the option that provides the most compression. That is, if you purposely leave extra white CRLF white space in a section, which should be parsed as a nop and allow the engine a few more slices to handle housekeeping chores, they may be ignored in the compression pairing, unless they have been marked with ; or { - } or //
Curly Braces:
If you are writing QBasic, in which line numbers not used by virtue of parsing CRLF to indicate a new line, then you could simply code without encapsulating your functions. However, in scripts that provide a function for multiple events: main(), talk(), hit(), for example, it can become important to identify where talk() ends, to prevent it from falling through and running hit(), as well. Sometimes it may function well but there is no guarantee it will continue to do so. We should not presume the parser will remember to compensate for our omissions every time, just because it did a few times. Do not code scripts to take advantage of a bug in the engine, such scripts could fail if that bug is fixed in an updated engine.
Again, we can always code using the goto format, which for specific things can be the best way to ensure that all paths are followed appropriately, but we must remember that a parsed language must read through the entire branch of code until it reaches the part it is to execute. In fact, imagine that line numbers are still required, for the sake of this discussion.
If we are on line 100 and "goto 250", it can count forward from 100 to 250. If however we are on line 250 and "goto 100", the parser cannot count down to 100, rather it starts counting from line 0 until it reaches 100, then executes. Though the parser uses white space and coding punctuations instead of line numbers, the process is the same. Goto is a command that allows a linear program to "appear to" mimic an oop object, but it is a much slower method than a true object.
The purpose of having a script refer to only 1 object and handle all of it's own properties, is to allow the message que to trigger the object to do it's own processing, rather than having a single script that must keep track of everything.
Anyone not encapsulating every object, as well as each of it's internal functions, within curly braces, is risking the introduction of bugs they couldn't imagine, including variable bleed through.
I'm open to be corrected on any part of this,
Mm.
I humbly disagree with not needing semicolons, and brackets certainly are essential, especially if there is some "optional" code segments which precede mandatory segments.
Semicolons:
If I remember correctly, the parser looks for white space greater than 1 space, to indicate the end of a line. This explains why only 1 white space can exist between elements in an equation, for example.
i.e. &num == 1;
would fail at the '1' because it is a set value which cannot be changed or referenced as a variable.
&num == 1
is likely to fail, because the assignment isn't complete and the actual value of &num may not be properly defined, even if it seems to be, "sometimes".
At the same time, there are different flavors of whites pace; a space, hard space, CR, LF, CRLF, TAB... though these may appear to look the same in your favorite editor, they would each result in a different amount of spacing in a text.
Using a Semicolon indicates that the assignment is complete, and requires at least 1 white space to allow the parser to click to the next interval. Extra spaces following a semicolon are ignored.
i.e.
&num == 1; //A number
&num == 1; //A number
are identical to the parser.
I would suggest using semicolons, "at least" to end each assignment statement, as well as any statement which signifies the end of the script, or would relinquish control back to the que. The semicolon would also serve as a return point for when the script gets it's next turn in the cycle. imho, it would be less likely to fail if you used a semicolon to complete a statement that maybe did not require one, than to fail because you omitted one that was required. Also, in Seth's original notes he said, that including multiple assignments on one line would likely work fine, but there were occasions the parser didn't read them right, and suggested to put one per line just to be sure. There are examples in his own scripts that assign 2 on the same line, though only a few times this occurs.
i.e.
&strength = 3; &defense = 1;
"should" work, though more complex assignements that deal with references may be quirky.
sp_seq(&mouse, 0); sp_brain(&mouse, 13); sp_pseq(&mouse,10);
May be a challenge and should be coded as,
sp_seq(&mouse, 0);
sp_brain(&mouse, 13);
sp_pseq(&mouse,10);
Another point worth mentioning, when using compress to make .D files, it uses a pairing system to accomplish much of it's compression. White space within quotes will be packed as a literal string counting how many spaces there are, outside a string it is likely to choose the option that provides the most compression. That is, if you purposely leave extra white CRLF white space in a section, which should be parsed as a nop and allow the engine a few more slices to handle housekeeping chores, they may be ignored in the compression pairing, unless they have been marked with ; or { - } or //
Curly Braces:
If you are writing QBasic, in which line numbers not used by virtue of parsing CRLF to indicate a new line, then you could simply code without encapsulating your functions. However, in scripts that provide a function for multiple events: main(), talk(), hit(), for example, it can become important to identify where talk() ends, to prevent it from falling through and running hit(), as well. Sometimes it may function well but there is no guarantee it will continue to do so. We should not presume the parser will remember to compensate for our omissions every time, just because it did a few times. Do not code scripts to take advantage of a bug in the engine, such scripts could fail if that bug is fixed in an updated engine.
Again, we can always code using the goto format, which for specific things can be the best way to ensure that all paths are followed appropriately, but we must remember that a parsed language must read through the entire branch of code until it reaches the part it is to execute. In fact, imagine that line numbers are still required, for the sake of this discussion.
If we are on line 100 and "goto 250", it can count forward from 100 to 250. If however we are on line 250 and "goto 100", the parser cannot count down to 100, rather it starts counting from line 0 until it reaches 100, then executes. Though the parser uses white space and coding punctuations instead of line numbers, the process is the same. Goto is a command that allows a linear program to "appear to" mimic an oop object, but it is a much slower method than a true object.
The purpose of having a script refer to only 1 object and handle all of it's own properties, is to allow the message que to trigger the object to do it's own processing, rather than having a single script that must keep track of everything.
Anyone not encapsulating every object, as well as each of it's internal functions, within curly braces, is risking the introduction of bugs they couldn't imagine, including variable bleed through.
I'm open to be corrected on any part of this,
Mm.
