About compiler error messages...

[Warfley]

Delphis error message is completely wrong, there is no case in which While ... do end would be correct. FPC's error message is also wrong but not as wrong as Delphis, because a do needs to be followed by an instruction which is in most cases terminated by a semicolon (note that begin-end block is nothing more than a composite instruction, and is like any other instruction usually terminated with a semicolon). That said, an instruction is only terminated by a semicolon in "most cases", the only case where this is not the case is an else expression, where the semicolon is ommited. Thats why the error message is actually wrong here, because before an else there should not be a semicolon:

Code: Pascal  [Select][+][-]

1. if ... then
2.   while ... do
3.     foo
4. else
5.   ...

But the thing here is, that the real error is something totally different, that it is a dangling else. Because the following syntax is (even though fucked up) allowed:

Code: Pascal  [Select][+][-]

1. if ... then
2.   while ... do
3. else
4.   ...

As this would be the same as

Code: Pascal  [Select][+][-]

1. if ... then
2.   while ... do begin end
3. else
4.   ...

i.e. having an empty statement in the while loop.

So the real error here should be something like "else without any if block found"

Edit: I must correct myself, I forgott that there is a case where there needs to be a semicolon before else, this is the case in a case statement:

Code: Pascal  [Select][+][-]

1. case ... of
2. ...:
3.   while ... do ;
4. else
5.   ...
6. end.

Honestly the "no semicolon before an else statement" rule is pretty stupid, its a special syntax that applys only in a single use case, and not even in the other case where else is used... The world would be a better place if this rule would not exist (just my oppinion because I always get this wrong in case ... of statements)

[PascalDragon]

Obviously, a very minor thing but, it would be nice to see correct error messages whenever possible.

The parser does not know at the moment of parsing the else that it is inside the statement block of the while-statement, it simply tries to read a statement (which can also be a begin … end block). Thus it ignores any else, until or end which will then be reacted to at the outside when trying to read the statement separator for the while loop (where the only valid possibilities are ;, end or finalization (the later for initialization sections)). As a catch all and error recovery (so that the parser can hopefully continue to provide further errors) it's simply a ; that is forcefully parsed if something else (in this case the else) is found. Delphi simply chose end here as recovery as the following would be valid:

Code: Pascal  [Select][+][-]

1. program TestErrorMessage;
2.  
3. begin
4.   while 1 > 2    do
5. end.

So no, there is nothing that can be improved for this without sacrificing other error locations.

Delphis error message is completely wrong, there is no case in which While ... do end would be correct.

Delphi's error message is just as valid, as it's allowed for the statement of the while … do statement to be empty, thus due to Pascal using statement separators the end of the surrounding block may follow directly. It's in most cases not in any way useful, but it's syntactially correct.

So the real error here should be something like "else without any if block found"

As said above the parser does not know about this.

Edit:

FPC's error message is also wrong but not as wrong as Delphis, because a do needs to be followed by an instruction which is in most cases terminated by a semicolon (note that begin-end block is nothing more than a composite instruction, and is like any other instruction usually terminated with a semicolon). That said, an instruction is only terminated by a semicolon in "most cases", the only case where this is not the case is an else expression, where the semicolon is ommited.

Pascal does not terminate statements, it separates them! This is a subtle, but important difference.

[Warfley]

Pascal does not terminate statements, it separates them! This is a subtle, but important difference.

Which is IMHO actually something bad about pascals syntax because it allows for omitting the ; before an end (and is also the reason why the stupid no ; before else thing exists), which in my oppinion is just a delayed compilation error, that occurs when you start to add lines later on.

But I think as this is one of the core syntax structures of pascal, this will never change, and overall pascal is pretty good so I can live with such drawbacks

As said above the parser does not know about this.

But isn't this pretty much just an implementation detail? I mean whats stopping the parser from, when encountering the error, doing some more checks? I mean such an error only occurs if the if is dangling, so can't the parser on encountering this unexpected else just traverse the already parsed nodes backwards until it finds either begin of current block or if, and if there is no if then this else is dangling?

[440bx]

The entire point is, why must it be replaced/insertatian by a keyword?????

Because the programmer typed a keyword - specifically "while" - that's one reason why.  The other reasons are , because putting a semicolon before the "else" does not create a valid statement and, there is a "begin" that is expecting an "end" which is the only keyword that doesn't start another statement that is valid in that case.  Those are the reasons why.

So the expected token can very well be a ";".

No, because a ";" in that case violates the rules of the Pascal grammar, therefore ";" there, is not a possibility that leads to a syntactically valid program.

Delphis error message is completely wrong, there is no case in which While ... do end would be correct.

In that case, all  the Pascal compilers that compile this are "completely wrong":

Code: Pascal  [Select][+][-]

1. program TestErrorMessage;
2.  
3. begin
4.   while 1 > 2    do
5. end.

That might be why Borland replaced the name "Pascal" with Delphi.   Since Free Pascal compiles that and, according to you "there is no case in which While ... do end would be correct.", maybe it should be called Free "Fred" (abbreviated F2... sounds like a fighter jet.)

The parser does not know at the moment of parsing the else that it is inside the statement block of the while-statement, it simply tries to read a statement (which can also be a begin … end block).

But, there is one thing the parser knows with complete certainty which is, it was not parsing an "if" statement because if it had been parsing an "if" statement, the "if" production would have consumed the "else".  Therefore, the parser knows that "else" in that location is incorrect.

Since, the "while" production is done and there is no "if", control returns to the compound statement production and that one know that "else" isn't a statement therefore no separating semicolon is valid.  Therefore, the only correct symbol, that does not start another statement, in that location is "end".

Anyway, I have the answer to my question... this is the first time and, the last one, I bring up anything about the correctness (or lack thereof) of error messages.

In any case, thank you for the explanation, I do appreciate it.

[Martin_fr]

The entire point is, why must it be replaced/insertatian by a keyword?????

Because the programmer typed a keyword - specifically "while" - that's one reason why.  The other reasons are , because putting a semicolon before the "else" does not create a valid statement and, there is a "begin" that is expecting an "end" which is the only keyword that doesn't start another statement that is valid in that case.  Those are the reasons why.

- The fact that the program compiles (in particular cases) is not saying anything. The error is fixed when the program does what its indented to do. Putting in an end is not fixing this.
- Also again. REPLACING the "else" by a ";" does compile.
- And, in your example it was not the "end" but the "." thereafter that made it compile....

If you role a dice often enough you get the desired number. That does not mean you can get it at will.

But you ignored the main point.
"else" is a type for "esel", the programmer never wanted to type a keyword.

[PascalDragon]

Pascal does not terminate statements, it separates them! This is a subtle, but important difference.

Which is IMHO actually something bad about pascals syntax because it allows for omitting the ; before an end (and is also the reason why the stupid no ; before else thing exists), which in my oppinion is just a delayed compilation error, that occurs when you start to add lines later on.

But I think as this is one of the core syntax structures of pascal, this will never change, and overall pascal is pretty good so I can live with such drawbacks

Correct. That will never change. Just like no semicolon in front of an else will never change.

As said above the parser does not know about this.

But isn't this pretty much just an implementation detail? I mean whats stopping the parser from, when encountering the error, doing some more checks? I mean such an error only occurs if the if is dangling, so can't the parser on encountering this unexpected else just traverse the already parsed nodes backwards until it finds either begin of current block or if, and if there is no if then this else is dangling?

Yes, it's an implementation detail, but that's simply how FPC's recursive descent parser is written. That's also not likely to change, especially as we have more important problems than apparently inaccurate error messages.

The parser does not know at the moment of parsing the else that it is inside the statement block of the while-statement, it simply tries to read a statement (which can also be a begin … end block).

But, there is one thing the parser knows with complete certainty which is, it was not parsing an "if" statement because if it had been parsing an "if" statement, the "if" production would have consumed the "else".  Therefore, the parser knows that "else" in that location is incorrect.

No, it does not know that. At least not in the sense that it's useful for better error messages. The function that parses an if-statement knows that it's inside an if-statement, but the recursively called parser functions don't know anything about that (because they don't need to for correct function!).

[440bx]

I was going to leave this alone but, I couldn't resist... sorry!

... apparently inaccurate error messages.

Apparently ?...

try this one:

Code: Pascal  [Select][+][-]

1. {$APPTYPE CONSOLE}
2.  
3. program TestMissingIdentifierExpression;
4. var
5.   IntegerV : integer;
6. begin
7.   IntegerV :=              div 3;
8. end.
9.  

which produces the following error message:

Free Pascal Compiler version 3.0.4 [2017/10/06] for x86_64
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Win64 for x64
Compiling TestMissingIdentifierInExpression.lpr
TestMissingIdentifierInExpression.lpr(7,28) Error: Illegal expression
TestMissingIdentifierInExpression.lpr(7,32) Fatal: Syntax error, ";" expected but "ordinal const" found
Fatal: Compilation aborted

FPC seems to expect semicolons a little more than it should (semicolon fetish maybe ?).  I really don't think that dividing by a semicolon will work in Pascal (it probably works in C though)

I agree with you, "apparently" FPC does emit the "occasional" inaccurate error message (it usually includes a request for a semicolon... I'm stocking up on those )

But... I have to admit, I should have used the example in this post to make the point instead of the more terse example I used in the OP.

[PascalDragon]

But... I have to admit, I should have used the example in this post to make the point instead of the more terse example I used in the OP.

I'll have to check which route the parser takes to get to the error for this. If we can easily improve an error message we do, but some are simply a sideeffect of the parser's structure and reworking that is more effort than it's worth (like for your original example). So if you find others please continue to remark them, but don't be disappointed if we say "sorry, nothing to be done there".

[440bx]

I'll have to check which route the parser takes to get to the error for this. If we can easily improve an error message we do, but some are simply a sideeffect of the parser's structure and reworking that is more effort than it's worth (like for your original example). So if you find others please continue to remark them, but don't be disappointed if we say "sorry, nothing to be done there".

I don't want to give the wrong impression.  I can tell that there are some areas in the compiler where the developers clearly made an effort to emit a reasonably good error message, in some cases, better than I expected.  I definitely appreciate that and, because of that, I thought it might be helpful to report error messages that can certainly be "improved".

I understand that some of the error messages are a result of the parser's structure.  That's normal.  OTH, it is usually possible to assert the current symbol is in the set of expected/valid symbols and, only if it is not, then add some code in there to do a bit of analysis to emit a reasonably accurate error message (at least something in the problem ballpark.) 

There are a number of places in FPC where the compiler seems to simply ask for a semicolon even if it doesn't make any sense to put a semicolon there.  The expression parser seems rather prone to that behavior.  Here is an example:

Code: Pascal  [Select][+][-]

1. begin
2.   IntegerA :=    := 1;
3. end.
4.  

replacing the numeral 1 with a semicolon doesn't help and neither does putting a semicolon between the ":=" and the numeral.  IOW, the problem in that statement isn't going to be solved with semicolons.

If the compiler stated that, after the first ":=" an identifier (or one of the unary operators) was expected, it wouldn't solve the entire problem but, it would be a step in the right direction.  After adding an identifier there (by the programmer of course), it could state that assigning within an expression is not allowed.

[marcov]

I understand that some of the error messages are a result of the parser's structure.  That's normal.  OTH, it is usually possible to assert the current symbol is in the set of expected/valid symbols and, only if it is not, then add some code in there to do a bit of analysis to emit a reasonably accurate error message (at least something in the problem ballpark.) 

One should also regard that it is often not as simple as checking an "if" before an "else", because that is more complicated due to possible nesting, and separation between scanner and actual parser.

[440bx]

One should also regard that it is often not as simple as checking an "if" before an "else", because that is more complicated due to possible nesting, and separation between scanner and actual parser.

No doubt there are a fair number of syntactic errors that can put the compiler in a bind because, as a result of the syntactic error, the statement is ambiguous and the compiler can only state what the valid possibilities are instead of emitting a message that unambiguously solves the problem.

What I am trying to point out is that, at least in some cases, what the compiler offers (often when it states that it expected a semicolon), is not even applicable to the solution.

[Martin_fr]

Bit of fun:

Ok, I got the one and only answer. And it is not 42. It is "&".
The error message should clearly suggest: & expected

For the below will compile, if an ampersand is inserted.

Code: Pascal  [Select][+][-]

1. program Project1;
2. {$mode objfpc}{$H+}
3.  
4. procedure &else;
5. begin
6. end;
7.  
8. begin
9.   while true do else;
10. end.
11.  

[440bx]

Ok, I got the one and only answer. And it is not 42. It is "&".
The error message should clearly suggest: & expected

There is a lot of fun to be had with the "&".