The numerical parser errors were rephrased to the "expected such-and-such" format except for the "floating point constant is out of range" error ("expected valid floating point constant" didn't seem quite appropriate). To determine which type of parser error occurs, the data type of the token is set to Double for numeric errors (previously the data type was set to None for all errors).
Numerical parser errors should only be used only when a numeric expression is expected. In other words, when a number constant is expected, but there is something wrong with the number, then the appropriate numeric parser error should be reported. In this case, the error should point where in the error is detected on the constant. However, when a non-numeric expression is expected, the error should point to the beginning of the constant. Consider the following two numerical parser errors (missing sign or digits in the exponent):
A = B + 1.2eIn the first statement, the error should point to the character following the "e" indicating that a sign or digit(s) were expected in the exponent. However, in the second statement, the same error does not make sense (pointing to the character after the "e"). The correct error should point to the "1" saying that a string expression was expected.
A$ = B$ + 1.2.e
The remaining parser error (unrecognizable character) was treated as a normal bad token with the proper translator error being reported so the "unrecognizable character" error should never occur. All the parser error reporting has been corrected. More work is expected once more commands are implemented.
[commit 885389f640] [commit 6de8df90b] [commit 82ebc0beab]
No comments:
Post a Comment
All comments and feedback welcomed, whether positive or negative.
(Anonymous comments are allowed, but comments with URL links or unrelated comments will be removed.)