freak wrote: Yes, the error in question is a semantic error, not a syntactic one.
That's what I would have expected him to say after my first question.
But I think the fact this is a semantic error and not a syntax error is a little debatable IMHO, that's why I wrote this -> http://www.purebasic.fr/english/viewtop ... 33#p465633
For a programming language the sum of lexical and syntactical properties is a set of rules that defines the set of valid symbols and the ways they can be combined together to construct a valid, complete program or a just a code fragment in that language.
So, for example
Code: Select all
Debug c\cil\maBut if you add further information to that fragment, like for example:
Code: Select all
Structure X
cil.f
EndStructure
Define c.X
Debug c\cil\ma
I would say the syntax is wrong because there is no semantic whatsoever in that code. It has no meaning. Its incoherent syntax, while formally valid line per line in a vacuum, is not valid as a whole, preventing you to derive any meaning from it.
What does it mean ? What could it mean ? You can't say it. It's broken. To me that is more a syntax error than a semantic one.
The compiler is not able to generate code for the above code, because the syntax is wrong and can not be translated to code.
Other times you have some kind of what I would call a semantic error, where you try to add a string to a number for example. In some language this can have an intrinsic semantic wrongness, the syntax could be valid but the semantic wrongness is big enough to stop the compiler from generating code.
In another language the compiler can assume from the semantic of the code maybe you would like to have them converted to a common type where the operation is possible. Other times is the programmer to make that explicit through some form of casting. That's all semantics.
On top of that you can have some kinds of semantic errors resulting in valid compilable code without any second guessing from the compiler but resulting in possible problems: data loss, loss of precision, etc.
These often results in the emission of warnings. This is potentially bad, unwanted semantic.
Anyway... where to place what involves some grey areas... after all these are all artificial separations, and different compilers may put similar errors in different categories depending on how they approach the problem of extracting meaning from the source code.
Here we are talking luxury. PB often could be more specific when reporting errors, this is one case: "cil is not a structure"
Instead you just understand something is wrong (in your code hopefully) and start looking closely at that line and its dependencies.
