eval6

We could also use some more arithmetic operators. We've seen how to cope with operators before though and there is little that is new to be said about these.

The grammar is fairly large, but quite simple. (Honest. More than half the productions are concerned with boolean and arithmetic expressions). To help with the readability, I've capitalised all non-terminals.

The main problem with this degree of complexity in the language is that although it is now possible create moderately complex programs, it is impractical to do so because of the way it treats the ends of lines. They are only handled at the top level of the parser, so each line has to be a complete item. It is not possible to split 'if' statements or 'loop's across lines. This will need to be corrected before we consider this to be a usable language.

The lexer.

This helps keep the parser simple and detects errors that bit earlier. The later we detect an error, the harder it gets to give a meaningful error message. Since keywords are indistinguishable from names until they are complete, we handle them by checking completed names against a table of keywords, and returning a value associated with that particular keyword. These values are declared in an enumerated type. We could return the index into the table and rely on particular values for the enumerated type, but that approach means keeping the order of words in the table in step with the order of enumeration of the values. Using the table to associate the values with the words is more reliable and more obvious to anyone reading the lexer code.

Operators are also known to the lexer now. Previously, we simply assumed that if a token wasn't a name or a number, then it must be an operator. The mod and rem operators are particular names, so these are checked for along with other keywords. (See 'rem' versus 'mod' for more more detail on these operators.) Many of the characters used for operators can be used in combinations to create other operators. To recognize these the routine FollowedBy() checks for these combinations and returns the correct code.

The syntactic grammer allows loops to be labelled, but we refer to these labels using 'LabelName's. A LabelName is returned as the value of the label. The difference is the presence of the colon. If we wanted to recognise a label in the syntax by returning the name and the colon as two tokens it would become difficult to distinguish between a label and an assignment without using two tokens of lookahead. Since the lexer has already seen the character following the name, it will know which it is provided we do not allow any white-space between the name and the colon in a label.

Since layout becomes important with complex programming structures, and everyone likes to lay things out their own way, we now treat newlines as just another form of white-space, relying entirely on keywords to guide the syntax analysis. It is also high time we added comments to our proglets.

The parser

'If' statements.

               ...
               If Not condition Then GoTo else_part
    then_part: StmtList
               goto end_if
    else_part: StmtList
    end_if:    ...

If the next keyword is 'else', we need to do something similar to jump over the 'else' StmtList. Reserve a space for the jump instruction and patch in the address when we reach the 'endif'.

A doddle.

Boolean expressions.

Loops.

The form of loop I've gone for is similar to an Ada loop. The simplest form is an infinite loop, but we can leave the loop using an 'exit' statement at any point within it - not just at the start or the end. 'Exit' statements come in conditional and unconditional forms, with positive and negative senses of the condition being available using 'exit when' and 'exit unless' respectively.

As with 'if' statements, we want to jump to the end of a block when we don't yet know where the end of that block is, so we have to leave a space somewhere to patch the appropriate address in once we do know it. The obvious place to do this is at the 'exit' statement, but what if we have two or more 'exit' statements? We would have to remember where each one is to be able to patch it. An easier scheme to implement is to deposit the end-of-loop address at the start of the loop. When we come to such a reference during execution we would just skip over it without doing anything. When parsing the body of the loop we always know where it started, so we can have as many exit statements as we like simply by fetching the end-of-loop address from the reference at the start of the loop, and we only have to patch one point once we know where the end of the loop is.

The grammar actually treats 'exit' statements as statements in their own right - i.e. they are not handled as part of the loop. While this makes multiple 'exit' statements easier to express, it has two other consequences. First, an exit may occurr outside any loop, and we have to give some thought to how we interpret this. Do we disallow it, or exit the proglet? Secondly, if the start-of-loop address is held in storage local to the ParseLoop() procedure, we will not be able to access it from ParseExit(). It has to be stored 'globally' to the parser.

Since loops cannot overlap other than by nesting one inside another, a stack-type structure would be appropriate for storing this information. An un-named exit then refers to the last entry on the stack. For a named exit, we have to scan the entries looking for a match to the name. If, when we push a new named loop onto the loop-stack, we check that no other loop has the same name, it does not matter in what order we search the loop-stack for a name. This stack is only used during parsing, to help with address patches. There is no run-time loop-structure.

'rem' versus 'mod'

(a rem b) only makes sense if b is an integer, so we round it off to the nearest integer before doing the rest of the operation. (The original value of b is unchanged. We only round a copy of it to carry out the rem).

Just in case you're not clear what the difference is, (a mod b) always lies in the range 0 <= x < b, whereas rem is defined such that (int(a / b) * b + (a rem b)) = a.

(-7 mod 3) is therefore 2, but (-7 rem 3) is -1.

Bit operations.

New assignment operators

It is easy to read

    a = a + 1

    Long_Variable_Name_1 = Long_Variable_Name_2 + 1

    Long_Variable_Name_1 += 1

The run statement.

    for (t = StartTime; t <= StopTime; t += StepTime) {...}