Syntax error until expected but else found

But how do we get
— From: The compiler found an incorrect keyword
— To: Therefore it must expect a keyword (just a different keyword)?

I didn’t say it  must expect a keyword.  What I said is, if it finds a keyword that does not start a new statement, as in the case with «else», then the keyword must be «end».  The reason for that is because the compiler is parsing a compound statement, therefore, it must expect a keyword to terminate the compound statement and, the _only_ keyword that does not start another statement that fulfills the requirement is «end». 

If the keyword «else» is wrong, we can conclude something else must be expected. But that something else can be anything: A new none-empty statement, an empty statement followed by a «;», an «end».

No, it cannot be anything.  What the compiler (Delphi) is saying, if you want a keyword that does not start another statement (as is the case with «else») there then it _must_ be «end». There is no other choice.

FPC stating that it expected a semicolon, in addition to being incorrect, it is also utterly useless because semicolons separate empty statements.  The compiler could ask for 200 semicolons there and achieve just as much.  It’s asking for a semicolon is the same (in that case) as asking for a space characters.  Utterly useless.

Following your argument, that the compiler should treat an unexpected keyword as a special error, then it should simply state
«incorrect keyword»

It’s not a special error.  A compound statement is terminated with «end».  There is no reason for the compiler to go «generic» and state «incorrect keyword» when it knows that the only acceptable keyword that does not start another statement is «end».    Since «else» does not start another statement then the only acceptable keyword that does not start another statement (as «else» is) is «end».

Yet, point in your favour:

1. repeat

2. while true do else

gives: Fatal: Syntax error, «UNTIL» expected but «ELSE» found
So it uses the knowledge about the outer block.

It’s not so much that it uses knowledge of the outer block, once the «while» is parsed, execution returns to the «repeat» production to finish parsing it, at that time, it finds an «else».  The only keyword that does not start another statement that «repeat» is going to accept is «until».  Since, «else» does not start another statement, the production demands an «until» keyword, as it should.

Personally, I would like to see the «; expected» error in the last case too. Just for consistency. (As both errors are equally good)

It really shouldn’t do that because, at some point the «repeat» production has to ask/demand the «until» it needs.  It can’t just go asking for another semicolon every time it needs an «until».

Of course, one has to ask why change the error at all.
Purely technically it is correct. (It is not complete, but it is one correct possibility, and neither would «end expected» be complete).

No, technically, it is incorrect.  That’s the problem, a compound statement is not ended with a semicolon, it’s ended with an «end» keyword.  It can’t keep asking for semicolons endlessly.  It really has to ask for the «end» and it has to ask for it whenever it  see a symbol that does not start a new statement, whatever it may be.

The reasons to change an error message are:
1- It is plain wrong (but this is a subset of the next point)
2- The message can be improved to give the user a better idea what is wrong.

The first does not apply.

On the contrary, the first applies in full.  The compound statement is not asking for its terminating symbol, that’s incorrect/wrong/bad/no good/trump.

Given that «;» is statistically more likely, the «; expected» error is actually ever so slightly more helpful.

Not if the programmer wants to eventually have a program that compiles because all the semicolons in the universe put before the else aren’t going to do it.

---

It is basically a summary of the state of the parser, not a correction advise. 

Error messages are not correction advise ? … if doing what they state isn’t going to lead to a correct statement then why does the compiler bother emitting them ?…  ascii visual entertainment ?…

Example: Delphi gives the exact same error for this code:

But, here is the thing you are attempting to avoid.  If you follow Delphi’s corrective «suggestions» (not advice, of course) you will eventually end up with a program that compiles.

Attempting to use FPC’s «ascii visual entertainment» yields a request for more and more semicolons and never a program that compiles successfully.

That applies to the example you showed.  I used your example.  Followed Delphi’s «suggestions» and after a few compiles had a syntactically correct program.  If I were still following FPC’s suggestion (not advice!) this entire post would be semicolons and the program would still not compile (and not ever compile.)

I think the Delphi solution is inferior.

Interesting that the solution that leads to a syntactically correct program is «inferior» while the «solution» that has the programmer adding semicolons for infinity is not inferior.

Anyway, I just wanted to know if there was interest in having correct error message.  I have the answer and, have no doubt about what it is.

Fatal: Syntax error, «.» expected but «;» found

1 Answer 1

The reason for this is that your begin s and end s are not balanced; disregarding the opening begin and closing end. for the program’s syntax to be correct, you should have equal numbers of each, but you have 4 begin s and 8 end s.

Obviously, your code is to compute the solutions of a quadratic equation. What I think you should do is to adjust the layout of your code so that it reflects that and then correctly the begin s and end s. In particular, your program is trying to detect whether any of a, b and d is zero and, if so, write a diagnostic message, otherwise calculate the roots by the usual formula.

Unfortunately, your begin s and end s do not reflect that. Either the whole of the block starting d := . needs to be executed or none of it does, so the else on the line before needs to be followed by a begin , as in

(You don’t say which Pascal compiler you are using, but the above fixes two points which are flagged as errors in FreePascal.

If you need more help than that, please ask in a comment.

Btw, there are some grammatical constructs in Pascal implementations where an end can appear without a matching preceding begin such as case . of . end .

Источник

Pascal fatal error «;» expected but else founded

What is causing the fatal error «;» expected but else founded message?

2 Answers 2

Unlike C, in Pascal a semicolon ; separates statements, it does not terminate them, and the then clause requires a single statement. then WriteLn(. ); else is two statements; you want then WriteLn(. ) else .

Let’s take this opportunity to learn how to read and use error messages to your advantage.

The compiler tells you exactly what the error is (it’s a ; before an else , because both of those are mentioned in the error message). It also gives you the exact line number where it’s reporting the error; that’s the number (usually in parentheses right before the error message, like (from Delphi):

[DCC Error] Project2.dpr(14): E2153 ‘;’ not allowed before ‘ELSE’

So the error is happening on line 14 (in my code — your number will be different). Let’s look at that line and a few before and after:

So look at the error message:

That clearly tells you that the ; in the line before the else is the problem (that’s very clear, because it says not allowed), so remove it.

BTW, now you’re going to get another error:

[DCC Error] Project2.dpr(15): E2003 Undeclared identifier: ‘wrtieln’

I think you should be able to figure that one out; again, the compiler gives you the exact line number.

You’re going to get another one, if you’ve posted your entire code:

[DCC Error] Project2.dpr(18): E2029 Statement expected but end of file found

This is because you’ve left out the end. that marks the end of a program file in Pascal. If you’ve not posted your entire code, you may not get it.

It’s important to learn to actually read the words when you get an error message from the compiler. In most languages, the messages are clearly worded, and they all have information you can use to try to figure out (or at least narrow down) the problems in your code.

Источник

Pascal fatal error «;» expected but else founded

What is causing the fatal error «;» expected but else founded message?

2 Answers 2

Unlike C, in Pascal a semicolon ; separates statements, it does not terminate them, and the then clause requires a single statement. then WriteLn(. ); else is two statements; you want then WriteLn(. ) else .

Let’s take this opportunity to learn how to read and use error messages to your advantage.

The compiler tells you exactly what the error is (it’s a ; before an else , because both of those are mentioned in the error message). It also gives you the exact line number where it’s reporting the error; that’s the number (usually in parentheses right before the error message, like (from Delphi):

[DCC Error] Project2.dpr(14): E2153 ‘;’ not allowed before ‘ELSE’

So the error is happening on line 14 (in my code — your number will be different). Let’s look at that line and a few before and after:

So look at the error message:

That clearly tells you that the ; in the line before the else is the problem (that’s very clear, because it says not allowed), so remove it.

BTW, now you’re going to get another error:

[DCC Error] Project2.dpr(15): E2003 Undeclared identifier: ‘wrtieln’

I think you should be able to figure that one out; again, the compiler gives you the exact line number.

You’re going to get another one, if you’ve posted your entire code:

[DCC Error] Project2.dpr(18): E2029 Statement expected but end of file found

This is because you’ve left out the end. that marks the end of a program file in Pascal. If you’ve not posted your entire code, you may not get it.

It’s important to learn to actually read the words when you get an error message from the compiler. In most languages, the messages are clearly worded, and they all have information you can use to try to figure out (or at least narrow down) the problems in your code.

Источник

[Паскалъ] Need Help

Что программа должна делать(на пхп)

ЕМНИП перед else там точка с запятой не ставится.

Не, ругается на другое, и спасибо это пофиксил.

> перед else там точка с запятой не ставится.

> ругается на другое

Условия в скобки попробуй.

Перед else ; не ставится.

У readln точно такой синтаксис? (я уже запамятовал)

Условия в скобки не надо?

Операции сравнения в скобки возьми.

А теперь, дружище, запомни, что вот этот выхлоп

untitled.pas(26,7) Error: Incompatible types: got «Boolean» expected «LongInt»
untitled.pas(28,2) Fatal: Syntax error, «;» expected but «ELSE» found

должен читать ТЫ сам, а не ЛОР.

Свободно говорю на Русском, Литовском, Английском.

Свободно говорю на Английском

Error: Incompatible types: got «Boolean» expected «LongInt»

Fatal: Syntax error, «;» expected but «ELSE» found

Источник

Почему выдаёт ошибку? Где я накосячила? Ошибка: unit1.pas(120,5) Fatal: Syntax error, «;» expected but «ELSE» found

procedure TForm1.RadioButton1Change(Sender: TObject);
begin
if radiobutton1.checked then
begin
edit1.text := IntToStr(Bin2Dec(edit1.text));
CS := 10;
s:=edit1.text
end;
else begin
edit1.text := IntToStr(Oct2Dec(edit1.text));
CS := 10;
s:=edit1.text;

Button1.Enabled:=True;
Button2.Enabled:=True;
Button3.Enabled:=True;
Button4.Enabled:=True;
Button5.Enabled:=True;
Button6.Enabled:=True;
Button7.Enabled:=True;
Button8.Enabled:=True;
Button9.Enabled:=True;
Button10.Enabled:=True;
Button11.Enabled:=True;
Button12.Enabled:=True;
Button13.Enabled:=True;
Button15.Enabled:=True;
Button16.Enabled:=True;
Button17.Enabled:=True;
Button18.Enabled:=True;
Button14.Enabled:=True;
Button19.Enabled:=True;
Button20.Enabled:=True;
Button21.Enabled:=True;
Button22.Enabled:=True;
Button23.Enabled:=True;
end;

—-исходный кусок ————
CS := 10;
s:=edit1.text
end;
else begin
————неправильно, д. б. так ——————-
CS := 10;
s:=edit1.text;
end
else begin

З. Ы. внимательнее с синтаксисом. лучше код форматировать отступами, вроде так:
begin
begin
.
end;
end;
сразу ясно какой энд какому бегину принадлежит )))

Источник