home *** CD-ROM | disk | FTP | other *** search
/ Power Programming / powerprogramming1994.iso / progtool / turbopas / tutorpas.arc / TUTOR4.DOC < prev    next >
Text File  |  1988-08-11  |  31KB  |  793 lines

  1. OPA A
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.                             LET'S BUILD A COMPILER!
  29.  
  30.                                        By
  31.  
  32.                             Jack W. Crenshaw, Ph.D.
  33.  
  34.                                   24 July 1988
  35.  
  36.  
  37.                              Part IV: INTERPRETERS
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65.  
  66.  
  67. PA A
  68.  
  69.  
  70.  
  71.  
  72.  
  73.        *****************************************************************
  74.        *                                                               *
  75.        *                        COPYRIGHT NOTICE                       *
  76.        *                                                               *
  77.        *   Copyright (C) 1988 Jack W. Crenshaw. All rights reserved.   *
  78.        *                                                               *
  79.        *****************************************************************
  80.  
  81.  
  82.        INTRODUCTION
  83.  
  84.        In the first three installments of this series,  we've  looked at
  85.        parsing and  compiling math expressions, and worked our way grad-
  86.        ually and methodically from dealing  with  very  simple one-term,
  87.        one-character "expressions" up through more general ones, finally
  88.        arriving at a very complete parser that could parse and translate
  89.        complete  assignment  statements,  with  multi-character  tokens,
  90.        embedded white space, and function calls.  This  time,  I'm going
  91.        to walk you through the process one more time, only with the goal
  92.        of interpreting rather than compiling object code.
  93.  
  94.        Since this is a series on compilers, why should  we  bother  with
  95.        interpreters?  Simply because I want you to see how the nature of
  96.        the  parser changes as we change the goals.  I also want to unify
  97.        the concepts of the two types of translators, so that you can see
  98.        not only the differences, but also the similarities.
  99.  
  100.        Consider the assignment statement
  101.  
  102.                       x = 2 * y + 3
  103.  
  104.        In a compiler, we want the target CPU to execute  this assignment
  105.        at EXECUTION time.  The translator itself doesn't  do  any arith-
  106.        metic ... it only issues the object code that will cause  the CPU
  107.        to do it when the code is executed.  For  the  example above, the
  108.        compiler would issue code to compute the expression and store the
  109.        results in variable x.
  110.  
  111.        For an interpreter,  on  the  other  hand, no object code is gen-
  112.        erated.   Instead, the arithmetic is computed immediately, as the
  113.        parsing is going on.  For the example, by the time parsing of the
  114.        statement is complete, x will have a new value.
  115.  
  116.        The approach we've been  taking  in  this  whole series is called
  117.        "syntax-driven translation."  As you are aware by now, the struc-
  118.        ture of the  parser  is  very  closely  tied to the syntax of the
  119.        productions we parse.  We  have built Pascal procedures that rec-
  120.        ognize every language  construct.   Associated with each of these
  121.        constructs (and procedures) is  a  corresponding  "action," which
  122.        does  whatever  makes  sense to do  once  a  construct  has  been
  123.        recognized.    In  our  compiler  so far, every  action  involves
  124.        emitting object code, to be executed later at execution time.  In
  125.        an interpreter, every action  involves  something  to be done im-
  126.        mediately.A*A*
  127.                                      - 2 -
  128. PA A
  129.  
  130.  
  131.  
  132.  
  133.  
  134.        What I'd like you to see here is that the  layout  ... the struc-
  135.        ture ... of  the  parser  doesn't  change.  It's only the actions
  136.        that change.   So  if  you  can  write an interpreter for a given
  137.        language, you can also write a compiler, and vice versa.  Yet, as
  138.        you  will  see,  there  ARE  differences,  and  significant ones.
  139.        Because the actions are different,  the  procedures  that  do the
  140.        recognizing end up being written differently.    Specifically, in
  141.        the interpreter  the recognizing procedures end up being coded as
  142.        FUNCTIONS that return numeric values to their callers.    None of
  143.        the parsing routines for our compiler did that.
  144.  
  145.        Our compiler, in fact,  is  what we might call a "pure" compiler.
  146.        Each time a construct is recognized, the object  code  is emitted
  147.        IMMEDIATELY.  (That's one reason the code is not very efficient.)
  148.        The interpreter we'll be building  here is a pure interpreter, in
  149.        the sense that there is  no  translation,  such  as "tokenizing,"
  150.        performed on the source code.  These represent  the  two extremes
  151.        of translation.  In  the  real  world,  translators are rarely so
  152.        pure, but tend to have bits of each technique.
  153.  
  154.        I can think of  several  examples.    I've already mentioned one:
  155.        most interpreters, such as Microsoft BASIC,  for  example, trans-
  156.        late the source code (tokenize it) into an  intermediate  form so
  157.        that it'll be easier to parse real time.
  158.  
  159.        Another example is an assembler.  The purpose of an assembler, of
  160.        course, is to produce object code, and it normally does that on a
  161.        one-to-one basis: one object instruction per line of source code.
  162.        But almost every assembler also permits expressions as arguments.
  163.        In this case, the expressions  are  always  constant expressions,
  164.        and  so the assembler isn't supposed to  issue  object  code  for
  165.        them.  Rather,  it  "interprets" the expressions and computes the
  166.        corresponding constant result, which is what it actually emits as
  167.        object code.
  168.  
  169.        As a matter of fact, we  could  use  a bit of that ourselves. The
  170.        translator we built in the  previous  installment  will dutifully
  171.        spit out object code  for  complicated  expressions,  even though
  172.        every term in  the  expression  is  a  constant.  In that case it
  173.        would be far better if the translator behaved a bit more  like an
  174.        interpreter, and just computed the equivalent constant result.
  175.  
  176.        There is  a concept in compiler theory called "lazy" translation.
  177.        The  idea is that you typically don't just  emit  code  at  every
  178.        action.  In fact, at the extreme you don't emit anything  at all,
  179.        until  you  absolutely  have to.  To accomplish this, the actions
  180.        associated with the parsing routines  typically  don't  just emit
  181.        code.  Sometimes  they  do,  but  often  they  simply  return in-
  182.        formation back to the caller.  Armed with  such  information, the
  183.        caller can then make a better choice of what to do.
  184.  
  185.        For example, given the statement
  186.  
  187.                       x = x + 3 - 2 - (5 - 4)  ,A*A*
  188.                                      - 3 -
  189. PA A
  190.  
  191.  
  192.  
  193.  
  194.  
  195.        our compiler will dutifully spit  out a stream of 18 instructions
  196.        to load each parameter into  registers,  perform  the arithmetic,
  197.        and store the result.  A lazier evaluation  would  recognize that
  198.        the arithmetic involving constants can  be  evaluated  at compile
  199.        time, and would reduce the expression to
  200.  
  201.                       x = x + 0  .
  202.  
  203.        An  even  lazier  evaluation would then be smart enough to figure
  204.        out that this is equivalent to
  205.  
  206.                       x = x  ,
  207.  
  208.        which  calls  for  no  action  at  all.   We could reduce 18  in-
  209.        structions to zero!
  210.  
  211.        Note that there is no chance of optimizing this way in our trans-
  212.        lator as it stands, because every action takes place immediately.
  213.  
  214.        Lazy  expression  evaluation  can  produce  significantly  better
  215.        object code than  we  have  been  able  to  so  far.  I warn you,
  216.        though: it complicates the parser code considerably, because each
  217.        routine now has to make decisions as to whether  to  emit  object
  218.        code or not.  Lazy evaluation is certainly not named that because
  219.        it's easier on the compiler writer!
  220.  
  221.        Since we're operating mainly on  the KISS principle here, I won't
  222.        go  into much more depth on this subject.  I just want you to  be
  223.        aware  that  you  can get some code optimization by combining the
  224.        techniques of compiling and  interpreting.    In  particular, you
  225.        should know that the parsing  routines  in  a  smarter translator
  226.        will generally  return  things  to  their  caller,  and sometimes
  227.        expect things as  well.    That's  the main reason for going over
  228.        interpretation in this installment.
  229.  
  230.  
  231.        THE INTERPRETER
  232.  
  233.        OK, now that you know WHY we're going into all this, let's do it.
  234.        Just to give you practice, we're going to start over with  a bare
  235.        cradle and build up the translator all over again.  This time, of
  236.        course, we can go a bit faster.
  237.  
  238.        Since we're now going  to  do arithmetic, the first thing we need
  239.        to do is to change function GetNum, which up till now  has always
  240.        returned a character  (or  string).    Now, it's better for it to
  241.        return an integer.    MAKE  A  COPY of the cradle (for goodness's
  242.        sake, don't change the version  in  Cradle  itself!!)  and modify
  243.        GetNum as follows:
  244.  
  245.  
  246.        {--------------------------------------------------------------}
  247.        { Get a Number }A6A6
  248.                                      - 4 -A*A*
  249. PA A
  250.  
  251.  
  252.  
  253.  
  254.  
  255.        function GetNum: integer;
  256.        begin
  257.           if not IsDigit(Look) then Expected('Integer');
  258.           GetNum := Ord(Look) - Ord('0');
  259.           GetChar;
  260.        end;
  261.        {--------------------------------------------------------------}
  262.  
  263.  
  264.        Now, write the following version of Expression:
  265.  
  266.  
  267.        {---------------------------------------------------------------}
  268.        { Parse and Translate an Expression }
  269.  
  270.        function Expression: integer;
  271.        begin
  272.           Expression := GetNum;
  273.        end;
  274.        {--------------------------------------------------------------}
  275.  
  276.  
  277.        Finally, insert the statement
  278.  
  279.  
  280.           Writeln(Expression);
  281.  
  282.  
  283.        at the end of the main program.  Now compile and test.
  284.  
  285.        All this program  does  is  to  "parse"  and  translate  a single
  286.        integer  "expression."    As always, you should make sure that it
  287.        does that with the digits 0..9, and gives an  error  message  for
  288.        anything else.  Shouldn't take you very long!
  289.  
  290.        OK, now let's extend this to include addops.    Change Expression
  291.        to read:
  292.  
  293.  
  294.        {---------------------------------------------------------------}
  295.        { Parse and Translate an Expression }
  296.  
  297.        function Expression: integer;
  298.        var Value: integer;
  299.        begin
  300.           if IsAddop(Look) then
  301.              Value := 0
  302.           else
  303.              Value := GetNum;
  304.           while IsAddop(Look) do begin
  305.              case Look of
  306.               '+': begin
  307.                       Match('+');
  308.                       Value := Value + GetNum;A*A*
  309.                                      - 5 -
  310. PA A
  311.  
  312.  
  313.  
  314.  
  315.  
  316.                    end;
  317.               '-': begin
  318.                       Match('-');
  319.                       Value := Value - GetNum;
  320.                    end;
  321.              end;
  322.           end;
  323.           Expression := Value;
  324.        end;
  325.        {--------------------------------------------------------------}
  326.  
  327.  
  328.        The structure of Expression, of  course,  parallels  what  we did
  329.        before,  so  we  shouldn't have too much  trouble  debugging  it.
  330.        There's  been  a  SIGNIFICANT  development, though, hasn't there?
  331.        Procedures Add and Subtract went away!  The reason  is  that  the
  332.        action to be taken  requires  BOTH arguments of the operation.  I
  333.        could have chosen to retain the procedures and pass into them the
  334.        value of the expression to date,  which  is Value.  But it seemed
  335.        cleaner to me to  keep  Value as strictly a local variable, which
  336.        meant that the code for Add and Subtract had to be moved in line.
  337.        This result suggests  that,  while the structure we had developed
  338.        was nice and  clean  for our simple-minded translation scheme, it
  339.        probably  wouldn't do for use with lazy  evaluation.    That's  a
  340.        little tidbit we'll probably want to keep in mind for later.
  341.  
  342.        OK,  did the translator work?  Then let's  take  the  next  step.
  343.        It's not hard to  figure  out what procedure Term should now look
  344.        like.  Change every call to GetNum in function  Expression  to  a
  345.        call to Term, and then enter the following form for Term:
  346.  
  347.  
  348.        {---------------------------------------------------------------}
  349.        { Parse and Translate a Math Term }
  350.  
  351.        function Term: integer;
  352.        var Value: integer;
  353.        begin
  354.           Value := GetNum;
  355.           while Look in ['*', '/'] do begin
  356.              case Look of
  357.               '*': begin
  358.                       Match('*');
  359.                       Value := Value * GetNum;
  360.                    end;
  361.               '/': begin
  362.                       Match('/');
  363.                       Value := Value div GetNum;
  364.                    end;
  365.              end;
  366.           end;
  367.           Term := Value;
  368.        end;
  369.        {--------------------------------------------------------------}A*A*
  370.                                      - 6 -
  371. PA A
  372.  
  373.  
  374.  
  375.  
  376.  
  377.        Now, try it out.    Don't forget two things: first, we're dealing
  378.        with integer division, so, for example, 1/3 should come out zero.
  379.        Second, even  though we can output multi-digit results, our input
  380.        is still restricted to single digits.
  381.  
  382.        That seems like a silly restriction at this point, since  we have
  383.        already  seen how easily function GetNum can  be  extended.    So
  384.        let's go ahead and fix it right now.  The new version is
  385.  
  386.  
  387.        {--------------------------------------------------------------}
  388.        { Get a Number }
  389.  
  390.        function GetNum: integer;
  391.        var Value: integer;
  392.        begin
  393.           Value := 0;
  394.           if not IsDigit(Look) then Expected('Integer');
  395.           while IsDigit(Look) do begin
  396.              Value := 10 * Value + Ord(Look) - Ord('0');
  397.              GetChar;
  398.           end;
  399.           GetNum := Value;
  400.        end;
  401.        {--------------------------------------------------------------}
  402.  
  403.  
  404.        If you've compiled and  tested  this  version of the interpreter,
  405.        the  next  step  is to install function Factor, complete with pa-
  406.        renthesized  expressions.  We'll hold off a  bit  longer  on  the
  407.        variable  names.    First, change the references  to  GetNum,  in
  408.        function Term, so that they call Factor instead.   Now  code  the
  409.        following version of Factor:
  410.  
  411.  
  412.        {---------------------------------------------------------------}
  413.        { Parse and Translate a Math Factor }
  414.  
  415.        function Expression: integer; Forward;
  416.  
  417.        function Factor: integer;
  418.        begin
  419.           if Look = '(' then begin
  420.              Match('(');
  421.              Factor := Expression;
  422.              Match(')');
  423.              end
  424.           else
  425.               Factor := GetNum;
  426.        end;
  427.        {---------------------------------------------------------------}ANAN
  428.                                      - 7 -A*A*
  429. PA A
  430.  
  431.  
  432.  
  433.  
  434.  
  435.        That was pretty easy, huh?  We're rapidly closing in on  a useful
  436.        interpreter.
  437.  
  438.  
  439.        A LITTLE PHILOSOPHY
  440.  
  441.        Before going any further, there's something I'd like  to  call to
  442.        your attention.  It's a concept that we've been making use  of in
  443.        all these sessions, but I haven't explicitly mentioned it up till
  444.        now.  I think it's time, because it's a concept so useful, and so
  445.        powerful,  that  it  makes all the difference  between  a  parser
  446.        that's trivially easy, and one that's too complex to deal with.
  447.  
  448.        In the early days of compiler technology, people  had  a terrible
  449.        time  figuring  out  how to deal with things like operator prece-
  450.        dence  ...  the  way  that  multiply  and  divide operators  take
  451.        precedence over add and subtract, etc.  I remember a colleague of
  452.        some  thirty years ago, and how excited he was to find out how to
  453.        do it.  The technique used involved building two  stacks,    upon
  454.        which you pushed each operator  or operand.  Associated with each
  455.        operator was a precedence level,  and the rules required that you
  456.        only actually performed an operation  ("reducing"  the  stack) if
  457.        the precedence level showing on top of the stack was correct.  To
  458.        make life more interesting,  an  operator  like ')' had different
  459.        precedence levels, depending  upon  whether or not it was already
  460.        on the stack.  You  had to give it one value before you put it on
  461.        the stack, and another to decide when to take it  off.   Just for
  462.        the experience, I worked all of  this  out for myself a few years
  463.        ago, and I can tell you that it's very tricky.
  464.  
  465.        We haven't  had  to  do  anything like that.  In fact, by now the
  466.        parsing of an arithmetic statement should seem like child's play.
  467.        How did we get so lucky?  And where did the precedence stacks go?
  468.  
  469.        A similar thing is going on  in  our interpreter above.  You just
  470.        KNOW that in  order  for  it  to do the computation of arithmetic
  471.        statements (as opposed to the parsing of them), there have  to be
  472.        numbers pushed onto a stack somewhere.  But where is the stack?
  473.  
  474.        Finally,  in compiler textbooks, there are  a  number  of  places
  475.        where  stacks  and  other structures are discussed.  In the other
  476.        leading parsing method (LR), an explicit stack is used.  In fact,
  477.        the technique is very  much  like the old way of doing arithmetic
  478.        expressions.  Another concept  is  that of a parse tree.  Authors
  479.        like to draw diagrams  of  the  tokens  in a statement, connected
  480.        into a tree with  operators  at the internal nodes.  Again, where
  481.        are the trees and stacks in our technique?  We haven't seen any.
  482.        The answer in all cases is that the structures are  implicit, not
  483.        explicit.    In  any computer language, there is a stack involved
  484.        every  time  you  call  a  subroutine.  Whenever a subroutine  is
  485.        called, the return address is pushed onto the CPU stack.   At the
  486.        end of the subroutine, the address is popped back off and control
  487.        is  transferred  there.   In a recursive language such as Pascal,A6A6
  488.                                      - 8 -A*A*
  489. PA A
  490.  
  491.  
  492.  
  493.  
  494.  
  495.        there can also be local data pushed onto the stack, and  it, too,
  496.        returns when it's needed.
  497.  
  498.        For example,  function  Expression  contains  a  local  parameter
  499.        called  Value, which it fills by a call to Term.  Suppose, in its
  500.        next call to  Term  for  the  second  argument,  that  Term calls
  501.        Factor, which recursively  calls  Expression  again.    That "in-
  502.        stance" of Expression gets another value for its  copy  of Value.
  503.        What happens  to  the  first  Value?    Answer: it's still on the
  504.        stack, and  will  be  there  again  when  we return from our call
  505.        sequence.
  506.  
  507.        In other words, the reason things look so simple  is  that  we've
  508.        been making maximum use of the resources of the  language.    The
  509.        hierarchy levels  and  the  parse trees are there, all right, but
  510.        they're hidden within the  structure  of  the parser, and they're
  511.        taken care of by the order with which the various  procedures are
  512.        called.  Now that you've seen how we do it, it's probably hard to
  513.        imagine doing it  any other way.  But I can tell you that it took
  514.        a lot of years for compiler writers to get that smart.  The early
  515.        compilers were too complex  too  imagine.    Funny how things get
  516.        easier with a little practice.
  517.  
  518.        The reason  I've  brought  all  this up is as both a lesson and a
  519.        warning.  The lesson: things can be easy when you do  them right.
  520.        The warning: take a look at what you're doing.  If, as you branch
  521.        out on  your  own,  you  begin to find a real need for a separate
  522.        stack or tree structure, it may be time to ask yourself if you're
  523.        looking at things the right way.  Maybe you just aren't using the
  524.        facilities of the language as well as you could be.
  525.  
  526.  
  527.        The next step is to add variable names.  Now,  though,  we have a
  528.        slight problem.  For  the  compiler, we had no problem in dealing
  529.        with variable names ... we just issued the names to the assembler
  530.        and let the rest  of  the program take care of allocating storage
  531.        for  them.  Here, on the other hand, we need to be able to  fetch
  532.        the values of the variables and return them as the  return values
  533.        of Factor.  We need a storage mechanism for these variables.
  534.  
  535.        Back in the early days of personal computing,  Tiny  BASIC lived.
  536.        It had  a  grand  total  of  26  possible variables: one for each
  537.        letter of the  alphabet.    This  fits nicely with our concept of
  538.        single-character tokens, so we'll  try  the  same  trick.  In the
  539.        beginning of your  interpreter,  just  after  the  declaration of
  540.        variable Look, insert the line:
  541.  
  542.                       Table: Array['A'..'Z'] of integer;
  543.  
  544.        We also need to initialize the array, so add this procedure:
  545.  
  546.  
  547.        {---------------------------------------------------------------}
  548.        { Initialize the Variable Area }A*A*
  549.                                      - 9 -
  550. PA A
  551.  
  552.  
  553.  
  554.  
  555.  
  556.        procedure InitTable;
  557.        var i: char;
  558.        begin
  559.           for i := 'A' to 'Z' do
  560.              Table[i] := 0;
  561.        end;
  562.        {---------------------------------------------------------------}
  563.  
  564.  
  565.        You must also insert a call to InitTable, in procedure Init.
  566.        DON'T FORGET to do that, or the results may surprise you!
  567.  
  568.        Now that we have an array  of  variables, we can modify Factor to
  569.        use it.  Since we don't have a way (so far) to set the variables,
  570.        Factor  will always return zero values for  them,  but  let's  go
  571.        ahead and extend it anyway.  Here's the new version:
  572.  
  573.  
  574.        {---------------------------------------------------------------}
  575.        { Parse and Translate a Math Factor }
  576.  
  577.        function Expression: integer; Forward;
  578.  
  579.        function Factor: integer;
  580.        begin
  581.           if Look = '(' then begin
  582.              Match('(');
  583.              Factor := Expression;
  584.              Match(')');
  585.              end
  586.           else if IsAlpha(Look) then
  587.              Factor := Table[GetName]
  588.           else
  589.               Factor := GetNum;
  590.        end;
  591.        {---------------------------------------------------------------}
  592.  
  593.  
  594.        As always, compile and test this version of the  program.    Even
  595.        though all the variables are now zeros, at least we can correctly
  596.        parse the complete expressions, as well as catch any badly formed
  597.        expressions.
  598.  
  599.        I suppose you realize the next step: we need to do  an assignment
  600.        statement so we can  put  something INTO the variables.  For now,
  601.        let's  stick  to  one-liners,  though  we will soon  be  handling
  602.        multiple statements.
  603.  
  604.        The assignment statement parallels what we did before:
  605.  
  606.  
  607.        {--------------------------------------------------------------}
  608.        { Parse and Translate an Assignment Statement }A6A6
  609.                                     - 10 -A*A*
  610. PA A
  611.  
  612.  
  613.  
  614.  
  615.  
  616.        procedure Assignment;
  617.        var Name: char;
  618.        begin
  619.           Name := GetName;
  620.           Match('=');
  621.           Table[Name] := Expression;
  622.        end;
  623.        {--------------------------------------------------------------}
  624.  
  625.  
  626.        To test this,  I  added  a  temporary write statement in the main
  627.        program,  to  print out the value of A.  Then I  tested  it  with
  628.        various assignments to it.
  629.  
  630.        Of course, an interpretive language that can only accept a single
  631.        line of program  is not of much value.  So we're going to want to
  632.        handle multiple statements.  This  merely  means  putting  a loop
  633.        around  the  call  to Assignment.  So let's do that now. But what
  634.        should be the loop exit criterion?  Glad you  asked,  because  it
  635.        brings up a point we've been able to ignore up till now.
  636.  
  637.        One of the most tricky things  to  handle in any translator is to
  638.        determine when to bail out of  a  given construct and go look for
  639.        something else.  This hasn't been a problem for us so far because
  640.        we've only allowed for  a  single kind of construct ... either an
  641.        expression  or an assignment statement.   When  we  start  adding
  642.        loops and different kinds of statements, you'll find that we have
  643.        to be very careful that things terminate properly.  If we put our
  644.        interpreter in a loop, we need a way to quit.    Terminating on a
  645.        newline is no good, because that's what sends us back for another
  646.        line.  We could always let an unrecognized character take us out,
  647.        but that would cause every run to end in an error  message, which
  648.        certainly seems uncool.
  649.  
  650.        What we need  is  a  termination  character.  I vote for Pascal's
  651.        ending period ('.').   A  minor  complication  is that Turbo ends
  652.        every normal line  with  TWO characters, the carriage return (CR)
  653.        and line feed (LF).   At  the  end  of  each line, we need to eat
  654.        these characters before processing the next one.   A  natural way
  655.        to do this would  be  with  procedure  Match, except that Match's
  656.        error  message  prints  the character, which of course for the CR
  657.        and/or  LF won't look so great.  What we need is a special proce-
  658.        dure for this, which we'll no doubt be using over and over.  Here
  659.        it is:
  660.  
  661.  
  662.        {--------------------------------------------------------------}
  663.        { Recognize and Skip Over a Newline }
  664.  
  665.        procedure NewLine;
  666.        begin
  667.           if Look = CR then begin
  668.              GetChar;
  669.              if Look = LF thenA*A*
  670.                                     - 11 -
  671. PA A
  672.  
  673.  
  674.  
  675.  
  676.  
  677.                 GetChar;
  678.           end;
  679.        end;
  680.        {--------------------------------------------------------------}
  681.  
  682.  
  683.        Insert this procedure at any convenient spot ... I put  mine just
  684.        after Match.  Now, rewrite the main program to look like this:
  685.  
  686.  
  687.        {--------------------------------------------------------------}
  688.        { Main Program }
  689.  
  690.        begin
  691.           Init;
  692.           repeat
  693.              Assignment;
  694.              NewLine;
  695.           until Look = '.';
  696.        end.
  697.        {--------------------------------------------------------------}
  698.  
  699.  
  700.        Note that the  test for a CR is now gone, and that there are also
  701.        no  error tests within NewLine itself.   That's  OK,  though  ...
  702.        whatever is left over in terms of bogus characters will be caught
  703.        at the beginning of the next assignment statement.
  704.  
  705.        Well, we now have a functioning interpreter.  It doesn't do  us a
  706.        lot of  good,  however,  since  we have no way to read data in or
  707.        write it out.  Sure would help to have some I/O!
  708.  
  709.        Let's wrap this session  up,  then,  by  adding the I/O routines.
  710.        Since we're  sticking to single-character tokens, I'll use '?' to
  711.        stand for a read statement, and  '!'  for a write, with the char-
  712.        acter  immediately  following  them  to  be used as  a  one-token
  713.        "parameter list."  Here are the routines:
  714.  
  715.        {--------------------------------------------------------------}
  716.        { Input Routine }
  717.  
  718.        procedure Input;
  719.        begin
  720.           Match('?');
  721.           Read(Table[GetName]);
  722.        end;
  723.  
  724.  
  725.        {--------------------------------------------------------------}
  726.        { Output Routine }
  727.  
  728.        procedure Output;
  729.        begin
  730.           Match('!');A*A*
  731.                                     - 12 -
  732. PA A
  733.  
  734.  
  735.  
  736.  
  737.  
  738.           WriteLn(Table[GetName]);
  739.        end;
  740.        {--------------------------------------------------------------}
  741.  
  742.        They aren't very fancy, I admit ... no prompt character on input,
  743.        for example ... but they get the job done.
  744.  
  745.        The corresponding changes in  the  main  program are shown below.
  746.        Note that we use the usual  trick  of a case statement based upon
  747.        the current lookahead character, to decide what to do.
  748.  
  749.  
  750.        {--------------------------------------------------------------}
  751.        { Main Program }
  752.  
  753.        begin
  754.           Init;
  755.           repeat
  756.              case Look of
  757.               '?': Input;
  758.               '!': Output;
  759.               else Assignment;
  760.              end;
  761.              NewLine;
  762.           until Look = '.';
  763.        end.
  764.        {--------------------------------------------------------------}
  765.  
  766.  
  767.        You have now completed a  real, working interpreter.  It's pretty
  768.        sparse, but it works just like the "big boys."  It includes three
  769.        kinds of program statements  (and  can  tell the difference!), 26
  770.        variables,  and  I/O  statements.  The only things that it lacks,
  771.        really, are control statements,  subroutines,    and some kind of
  772.        program editing function.  The program editing part, I'm going to
  773.        pass on.  After all, we're  not  here  to build a product, but to
  774.        learn  things.    The control statements, we'll cover in the next
  775.        installment, and the subroutines soon  after.  I'm anxious to get
  776.        on with that, so we'll leave the interpreter as it stands.
  777.  
  778.        I hope that by  now  you're convinced that the limitation of sin-
  779.        gle-character names  and the processing of white space are easily
  780.        taken  care  of, as we did in the last session.   This  time,  if
  781.        you'd like to play around with these extensions, be my  guest ...
  782.        they're  "left as an exercise for the student."    See  you  next
  783.        time.
  784.  
  785.        *****************************************************************
  786.        *                                                               *
  787.        *                        COPYRIGHT NOTICE                       *
  788.        *                                                               *
  789.        *   Copyright (C) 1988 Jack W. Crenshaw. All rights reserved.   *
  790.        *                                                               *
  791.        *****************************************************************A*A*
  792.                                     - 13 -
  793. @