Recent

Author Topic: It has a little bug in IDE  (Read 10630 times)

MarkMLl

  • Hero Member
  • *****
  • Posts: 2844
Re: It has a little bug in IDE
« Reply #15 on: June 19, 2021, 11:43:21 pm »
Consider the following simple example: the if statement is being parsed, after the "then" token the if_rule procedure has called the statement_rule procedure.  The statement_rule procedure returns consuming the semicolon. Now what to expect? Another semicolon because "if" is also a statement (and must be terminated)? "else" because there is an else clause? or some other statement?  You can't tell for sure that the current if_rule is completed or not. You must take a decision and eventually to backtrack if it was wrong.


ifSt = 'IF' expression 'THEN' .OUT('DUP' '0') .OUT('BRF' *1)
        statementSeq .LABEL *1
        ifElsePart 'END';

ifElsePart = ('ELSE' .OUT('BRT' *1) statementSeq .LABEL *1) |
        (.EMPTY .OUT('STO' '__undefined__'));

(* If statement. Note that care is required to make sure that the   *)
(* stack is consistent whether or not there is an else part.      *)


That's Meta-2 notation which you're probably unfamiliar with (Schorre, 1964), but basically "it just works" if you look for "else..." | nothing. My company's running on that code.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

440bx

  • Hero Member
  • *****
  • Posts: 2429
Re: It has a little bug in IDE
« Reply #16 on: June 20, 2021, 12:02:34 am »
And BTW, the "end" is perfectly valid to follow "begin".
Yes, it is and the reason has nothing to do with semicolons, it has everything to do with the fact that Pascal accepts whitespace (or a comment) as a null statement (incidentally, just as C does but, in C if whitespace is used as a null statement then the null statement must be terminated just like any other statement)

No. "end" is definitely not a delimiter. It is a terminal symbol which stands at the end of the <compound statement> rule (and some others too).
It's a "delimiter" in the sense that it marks the end of a compound statement (unfortunately, among other things.) 

I see. You named it (as separator, terminator) according to when it appears to be between or at the end of the "list".
This isn't just a choice I made.  C uses semicolons as a statement terminator whereas Pascal uses it as a statement separator.  In strict Pascal (the original McCoy) the last statement in a compound statement cannot be followed by a semicolon because if the compiler sees a semicolon it expects a keyword (or identifier) that starts another statement.  That is not the case in C.  In C, the last statement in a compound statement {...} must be ended by a semicolon just like any other statement because it explicitly marks the end of the statement.

This definition { statement ";" } will introduce ambiguity which changes grammar to LL(k). This is why you can't parse C grammar with a (naive) recursive descent parser.
It wouldn't.  It definitely would not cause the grammar to change to LL(k).  For the record, Pascal cannot be parsed with a "naive" recursive descent parser either (at least not strictly based on its grammar.)

Consider the following simple example: the if statement is being parsed, after the "then" token the if_rule procedure has called the statement_rule procedure.
In that case the compiler expects a _simple_ statement.

The statement_rule procedure returns consuming the semicolon. Now what to expect?
It must expect, either another statement (that is a new statement not part of the "if") or an "end" keyword that terminates a compound statement (or a procedure/function block.)

Another semicolon because "if" is also a statement (and must be terminated)? "else" because there is an else clause? or some other statement?  You can't tell for sure that the current if_rule is completed or not. You must take a decision and eventually to backtrack if it was wrong.
No, there is no need for multiple semicolons.  if multiple semicolons appeared then they would either be separators between null statements (as in Pascal) or null statement terminators (as in C.)

FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

y.ivanov

  • Full Member
  • ***
  • Posts: 192
Re: It has a little bug in IDE
« Reply #17 on: June 20, 2021, 02:53:55 am »
@440bx
Well, let's argue whether to put a semicolon in C as follows {{};};
I'm bailing out of this...

Good point. It is written in the subject: it is about the IDE.
Maybe it must be discussed elsewhere.

I'd throw in a couple of related points before this discussion completely winds down. First, at least some of the ALGOL implementations describe anything after END as being an implicit comment, with minimal consideration of the status of ; in that context. Second, the END. at the end of an ALGOL (hence Pascal) program was a non-standard "hack" from Burroughs that allowed the compiler to decide that it had seen enough without reading the next card which would potentially have screwed up the remainder of the batch job (and their compilers insist that nothing follow it).

I've spent a bit of time over the last few weeks looking at Verilog and VHDL, and it's an interesting exercise speculating which bits are unarguably ALGOL, which bits are unarguably Ada, and which bits are probably Ada but the sub-sub-sub-committee had their own idea about the END behaviour and didn't agree with the guys in the next office :-)

Mark, thanks for sharing this. I'm personally very curious about such a first-person views on a computers development (and this is with the utmost respect). The time the computers came in my country, or I came into computers, it was about ~10 years gap from the IT developed (western) countries. That was the time for the engineers to reverse engineer the  IBM/360, VAX PDP-8, VME, etc. The clones were declared as genuine, the others were not mentioned at all.
So, I'm now truly interested in that unknown (for me) development. Languages as ALGOL, MPL, even COBOL - these are lost, skipped for me. But, as it turns out, every one of these has its implications on what we do now.

As I previously said, maybe it is a subject for a separate discussion.

 

TinyPortal © 2005-2018