13.5. Calling The Procedure

If you're satisfied that things are working, let's address the second half of the equation … the call.

Consider the BNF for a procedure call:

     <proc_call> ::= <identifier>

for an assignment statement, on the other hand, the BNF is:

     <assignment> ::= <identifier> '=' <expression>

At this point we seem to have a problem. The two BNF statements both begin on the right-hand side with the token <identifier>. How are we supposed to know, when we see the identifier, whether we have a procedure call or an assignment statement? This looks like a case where our parser ceases being predictive, and indeed that's exactly the case. However, it turns out to be an easy problem to fix, since all we have to do is to look at the type of the identifier, as recorded in the symbol table. As we've discovered before, a minor local violation of the predictive parsing rule can be easily handled as a special case.

Here's how to do it:

{ Parse and Translate an Assignment Statement }
procedure Assignment(Name: char);

{ Decide if a Statement is an Assignment or Procedure Call }
procedure AssignOrProc;
var Name: char;
     Name := GetName;
     case TypeOf(Name) of
          ' ': Undefined(Name);
          'v': Assignment(Name);
          'p': CallProc(Name);
          else Abort('Identifier ' + Name +
                                   ' Cannot Be Used Here');

{ Parse and Translate a Block of Statements }
procedure DoBlock;
     while not(Look in ['e']) do begin

As you can see, procedure Block now calls AssignOrProc instead of Assignment. The function of this new procedure is to simply read the identifier, determine its type, and then call whichever procedure is appropriate for that type. Since the name has already been read, we must pass it to the two procedures, and modify Assignment to match. Procedure CallProc is a simple code generation routine:

{ Call a Procedure }
procedure CallProc(N: char);
     EmitLn('BSR ' + N);

Well, at this point we have a compiler that can deal with procedures. It's worth noting that procedures can call procedures to any depth. So even though we don't allow nested DECLARATIONS, there is certainly nothing to keep us from nesting CALLS, just as we would expect to do in any language. We're getting there, and it wasn't too hard, was it?

Of course, so far we can only deal with procedures that have no parameters. The procedures can only operate on the global variables by their global names. So at this point we have the equivalent of BASIC's GOSUB construct. Not too bad … after all lots of serious programs were written using GOSUBs, but we can do better, and we will. That's the next step.