There are, it appears, three types of errors to be found in any computer program, and LSL gives everyone ample opportunity to create scads of each type:
- syntax errors;
- semantic errors;
- program logic errors.
Syntax is the grammar of the language; a statement in LSL is like a sentence. Variable names, operators, string or number literals, and function parameters must be in their proper place within the statement. Common syntax errors in LSL include, for instance, missing terminating semicolons and unbalanced parentheses, braces, or double-quote marks.
Semantic errors occur when the syntax is correct but the meaning of the token or expression is disallowed. These can be subtle and may require a bit more deduction from your little grey cells.
An easily apparent semantic error is the following global variable declaration:
[lsl]
integer x = "Hello!" ;
[/lsl]
Most grammars are general about the syntax; this statement’s syntax is probably checked as:
[lsl]
type-name identifier = literal ;
[/lsl]
where “identifier” is a token word to be used as a new variable name, and “literal” is a class of tokens usually encompassing explicit strings, numbers, vectors, and rotations. Remember that global variables cannot be initialized with function calls or by expressions with operators.
So the above nonsensical statement passes the syntax check. Then the compiler must check the meaning of the tokens encountered. Was “x” defined before this in scope? If so, it’s a semantic error! Even then, a string cannot be assigned to an integer variable in LSL, so compilation ends with a semantic error flagged when the compiler reads the string literal.
I’ll not dwell on logic errors here, except to say that those errors are discovered when compilation completes without error but the program doesn’t do what you expect. These errors can be far subtler than semantic errors, and that’s when the real debugging starts!
So why have I bothered to state what most people learn in the first few days of their programming life? Because some people don’t.
Syntax errors are by far the easiest of these three classes of errors to identify and correct, and yet so many people post–in group chat, no less–a line of code with an obvious grammatical error and then ask, “What’s wrong with this?”
Generally speaking, if the compilation reports a syntax error, then you should seriously consider the possibility that you have a syntax error. The error is at or just before the reported line and position. Unbalanced braces may not be caught until the start of the next event code, but even that is a clue to look for that specific error in the previous routine.
If you cannot identify a syntax error, then you don’t understand the very basics of the language. Learn it.
Ideally there should be no reason to ask in group chat for others to point out a simple grammatical error. It shows that you’re not thinking and you’re not looking, and instead you are wasting other people’s time. Contrary to public wisdom–now there’s an oxymoron if I ever heard one!–there are such things as stupid questions.
That’s the ideal, of course. And there’s one exception which we have all encountered. There are times when you are told there’s a syntax error, and you look at it, and you look at it, and you look at it, and you just can’t see it, even though you’re told it’s right in front of your face. If this hasn’t happened to you at least once in your life, you’re lying.
Then, and not before, is the time to ask for help. Whomever you ask, whether in private or in group chat, don’t just ask what’s wrong. Give them more information, including the wording of the error message.
Logic errors can be very difficult to find; semantic errors much less so. But if you need help finding a simple syntax error, then be prepared to hear an [un]intentional laugh or two. It may not be a nice thing to do, but they may not be unjustified.
Originally posted 05 Oct 2008
Last edited 06 Oct 2008