replace delphi syntax highlighting with pascal

react-tuto/lbac-markdown/tutor01_introduction.md

@@ -188,7 +188,7 @@ stream.  No other special  techniques are required with Turbo 4.0
 in the stream.
 
 
-```delphi
+```pascal
 
 {--------------------------------------------------------------}
 program Cradle;

react-tuto/lbac-markdown/tutor02_expressionparsing.md

@@ -29,7 +29,7 @@ Before starting to code, make sure you have a  baseline  copy  of
 the  "cradle" that I gave last time.  We'll be using it again for
 other experiments.  Then add this code:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Math Expression }
 
@@ -43,7 +43,7 @@ end;
 And add the  line  "Expression;"  to  the main program so that it
 reads:
                               
-```delphi
+```pascal
 {---------------------------------------------------------------}
 begin
    Init;
@@ -109,7 +109,7 @@ as Term, and enter the following new version of Expression:
 
 
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate an Expression }
 
@@ -128,7 +128,7 @@ end;
 
 Next, just above Expression enter these two procedures:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate an Add }
 
@@ -202,7 +202,7 @@ the wrong way, so we end up with the wrong  sign  for the result.
 So let's fix up procedure Subtract with a  sign-changer,  so that
 it reads
 
-```delphi
+```pascal
 {-------------------------------------------------------------}
 { Recognize and Translate a Subtract }
 
@@ -248,7 +248,7 @@ written `<expression> ::= <term> [<addop> <term>]*`
 We  can  accomodate  this definition of an  expression  with  the
 addition of a simple loop to procedure Expression:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate an Expression }
 
@@ -315,15 +315,15 @@ written `-(SP)` and a pop, `(SP)+` .
 
 
 So let's change the EmitLn in Expression to read:
-```delphi
+```pascal
                EmitLn('MOVE D0,-(SP)');
 ```
 and the two lines in Add and Subtract to
-```delphi
+```pascal
                EmitLn('ADD (SP)+,D0')
 ```
 and
-```delphi
+```pascal
             EmitLn('SUB (SP)+,D0'),
 ```
 respectively.  Now try the parser again and make sure  we haven't
@@ -362,7 +362,7 @@ judicious  copying and renaming.  But  to  avoid  confusion,  the
 listing below is the complete set of parsing routines.  (Note the
 way we handle the reversal of operands in Divide.)
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Math Factor }
 
@@ -488,7 +488,7 @@ etc., ad infinitum.
 Complicated or not, we can take care of this by adding just a few
 lines of Pascal to procedure Factor:
                              
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Math Factor }
 
@@ -532,7 +532,7 @@ becomes 0-3.  We can easily patch this into our  existing version
 of Expression:
 
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate an Expression }
 
@@ -560,7 +560,7 @@ function IsAddop.  Since the test for an addop appeared  twice, I
 chose  to  embed  it in the new function.  The  form  of  IsAddop
 should be apparent from that for IsAlpha.  Here it is:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize an Addop }
 

react-tuto/lbac-markdown/tutor03_moreexpressions.md

@@ -64,7 +64,7 @@ format for a load in this language is `MOVE X(PC),D0`
 where X is, of course, the variable name.  Armed with that, let's
 modify the current version of Factor to read:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Math Factor }
 
@@ -134,7 +134,7 @@ Now that there are two  possibilities for the "If IsAlpha" branch
 of the test in Factor, let's treat them in a  separate procedure.
 Modify Factor to read:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Math Factor }
 
@@ -157,7 +157,7 @@ end;
 
 and insert before it the new procedure
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate an Identifier }
 
@@ -244,14 +244,14 @@ To see what I'm talking about, try the input line
 See  how the space was treated as a terminator?  Now, to make the
 compiler properly flag this, add the line
 
-```delphi
+```pascal
                if Look <> CR then Expected('Newline');
 ```
 in the main  program,  just  after  the call to Expression.  That
 catches anything left over in the input stream.  Don't  forget to
 define CR in the const statement:
 
-```delphi
+```pascal
                CR = ^M;
 ```
 
@@ -278,7 +278,7 @@ We're only a breath  away  from being able to parse an assignment
 statement, so let's take that  last  step.  Just  after procedure
 Expression, add the following new procedure:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate an Assignment Statement }
 
@@ -351,7 +351,7 @@ must be a letter, but the rest can be  alphanumeric  (letters  or
 numbers).  To  deal  with  this,  we  need  one  other recognizer
 function
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize an Alphanumeric }
 
@@ -369,7 +369,7 @@ member of Cradle, too.
 Now, we need  to  modify  function  GetName  to  return  a string
 instead of a character:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get an Identifier }
 
@@ -389,7 +389,7 @@ end;
 
 Similarly, modify GetNum to read:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get a Number }
 
@@ -445,7 +445,7 @@ modify.
 Not  surprisingly,  we  start  with  yet  another  new recognizer
 routine:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize White Space }
 
@@ -459,7 +459,7 @@ end;
 We  also need a routine that  will  eat  white-space  characters,
 until it finds a non-white one:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Skip Over Leading White Space }
 
@@ -474,7 +474,7 @@ end;
 Now,  add calls to SkipWhite to Match,  GetName,  and  GetNum  as
 shown below:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Match a Specific Input Character }
 
@@ -528,7 +528,7 @@ functionality.)
 Finally, we need to skip over leading blanks where we  "prime the
 pump" in Init:
 
-```delphi                        
+```pascal                        
 {--------------------------------------------------------------}
 { Initialize }
 
@@ -548,7 +548,7 @@ make sure it works properly.
 Since we've made quite  a  few  changes  during this session, I'm
 reproducing the entire parser below:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 program parse;
 

react-tuto/lbac-markdown/tutor04_interpreters.md

@@ -151,7 +151,7 @@ return an integer.    MAKE  A  COPY of the cradle (for goodness's
 sake, don't change the version  in  Cradle  itself!!)  and modify
 GetNum as follows:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get a Number }
 
@@ -166,7 +166,7 @@ end;
 
 Now, write the following version of Expression:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate an Expression }
 
@@ -193,7 +193,7 @@ anything else.  Shouldn't take you very long!
 OK, now let's extend this to include addops.    Change Expression
 to read:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate an Expression }
 
@@ -242,7 +242,7 @@ call to Term, and then enter the following form for Term:
 
 
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Math Term }
 
@@ -275,7 +275,7 @@ That seems like a silly restriction at this point, since  we have
 already  seen how easily function GetNum can  be  extended.    So
 let's go ahead and fix it right now.  The new version is
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get a Number }
 
@@ -302,7 +302,7 @@ following version of Factor:
 
 
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Math Factor }
 
@@ -427,7 +427,7 @@ We also need to initialize the array, so add this procedure:
 
 
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Initialize the Variable Area }
 
@@ -448,7 +448,7 @@ use it.  Since we don't have a way (so far) to set the variables,
 Factor  will always return zero values for  them,  but  let's  go
 ahead and extend it anyway.  Here's the new version:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Math Factor }
 
@@ -481,7 +481,7 @@ multiple statements.
 
 The assignment statement parallels what we did before:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate an Assignment Statement }
                              
@@ -532,7 +532,7 @@ and/or  LF won't look so great.  What we need is a special proce-
 dure for this, which we'll no doubt be using over and over.  Here
 it is:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Skip Over a Newline }
 
@@ -550,7 +550,7 @@ end;
 Insert this procedure at any convenient spot ... I put  mine just
 after Match.  Now, rewrite the main program to look like this:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 
@@ -579,7 +579,7 @@ stand for a read statement, and  '!'  for a write, with the char-
 acter  immediately  following  them  to  be used as  a  one-token
 "parameter list."  Here are the routines:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Input Routine }
 
@@ -607,7 +607,7 @@ The corresponding changes in  the  main  program are shown below.
 Note that we use the usual  trick  of a case statement based upon
 the current lookahead character, to decide what to do.
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 

react-tuto/lbac-markdown/tutor05_controlstructs.md

@@ -47,7 +47,7 @@ just echo the character input.
 OK, then, starting with  yet  another  copy  of the cradle, let's
 define the procedure:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate an "Other" }
 
@@ -60,7 +60,7 @@ end;
 
 Now include a call to it in the main program, thus:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 
@@ -95,7 +95,7 @@ statement.
 Armed with these ideas, we can proceed to build  up  our  parser.
 The code for a program (we  have  to call it DoProgram, or Pascal
 will complain, is:
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Program }
 
@@ -114,7 +114,7 @@ sense considering that we're parsing a complete program here.
 
 The code for Block is:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate a Statement Block }
 
@@ -198,7 +198,7 @@ outputs the labels at the proper place.
 
 Here are the two routines:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Generate a Unique Label }
 
@@ -225,14 +225,14 @@ Notice that we've added  a  new  global  variable, LCount, so you
 need to change the VAR declarations at the top of the  program to
 look like this:
 
-```delphi
+```pascal
 var Look  : char;              { Lookahead Character }
     Lcount: integer;           { Label Counter }
 ```
 
 Also, add the following extra initialization to Init:
 
-```delphi
+```pascal
    LCount := 0;
 ```
 (DON'T forget that, or your labels can look really strange!)
@@ -307,7 +307,7 @@ also, for now, skip completely  the character for the branch con-
 dition, which we still have to define.
 
 The code for DoIf is:
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate an IF Construct }
 
@@ -331,7 +331,7 @@ end;
 Add this routine to your program, and change  Block  to reference
 it as follows:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate a Statement Block }
 
@@ -353,7 +353,7 @@ dition we care to give it.  But  that's  a  whole  installment by
 itself (the next one, in fact).    For  now, let's just make it a
 dummy that emits some text.  Write the following routine:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Boolean Condition }
 { This version is a dummy }
@@ -421,7 +421,7 @@ as to how to handle both situations.   The  code  below  does it.
 (Note that I  use  an  'l'  for  the ELSE, since 'e' is otherwise
 occupied):
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate an IF Construct }
 
@@ -511,7 +511,7 @@ needed at each point.
 
 The code follows immediately from the syntax:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a WHILE Statement }
 
@@ -535,7 +535,7 @@ end;
 Since  we've  got a new statement, we have to add a  call  to  it
 within procedure Block:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate a Statement Block }
 
@@ -603,7 +603,7 @@ The corresponding code is shown below.  Since  I've  already used
 'l'  for  the  ELSE, I've used  the  last  letter,  'p',  as  the
 "keyword" this time.
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a LOOP Statement }
 
@@ -647,7 +647,7 @@ and the syntax-directed translation is:
 
 As usual, the code falls out pretty easily:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a REPEAT Statement }
 
@@ -673,7 +673,7 @@ the while-test.  These  are  the  characters  that signal an exit
 from the current  block  ... the "follow" characters, in compiler
 jargon.
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate a Statement Block }
 
@@ -764,7 +764,7 @@ better, please let me know.
 Still, the parser  routine  is  pretty  easy now that we have the
 code:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a FOR Statement }
 
@@ -802,7 +802,7 @@ end;
 Since we don't have  expressions  in this parser, I used the same
 trick as for Condition, and wrote the routine
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate an Expression }
 { This version is a dummy }
@@ -852,7 +852,7 @@ The syntax and its translation is:
 That's quite a bit simpler!  The loop will execute  `<expr>` times.
 Here's the code:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a DO Statement }
 
@@ -919,7 +919,7 @@ whatever label is above it and passes its own exit label along.
 All  this  is easier to show you than it is to  describe.    I'll
 demonstrate with the easiest loop, which is LOOP:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a LOOP Statement }
 
@@ -946,7 +946,7 @@ up things a bit, but there's no harm done.
 Note also that Block now has a parameter, which  for  loops  will
 always be the exit address.  The new version of Block is:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate a Statement Block }
 
@@ -973,7 +973,7 @@ into DoIf and  DoBreak.    The  loop  constructs  don't  need it,
 because they are going to pass their own label anyway.
 
 The new version of DoIf is:
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate an IF Construct }
 
@@ -1013,7 +1013,7 @@ pass it a label.  An  attempt  to  exit the outermost block is an
 error, so DoProgram  passes  a  null  label  which  is  caught by
 DoBreak:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate a BREAK }
 
@@ -1056,7 +1056,7 @@ Here's a version that doesn't have the problem:
 
 
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a DO Statement }
 
@@ -1107,7 +1107,7 @@ session:
 
 
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 program Branch;
 

react-tuto/lbac-markdown/tutor06_booleanexpressions.md

@@ -346,7 +346,7 @@ of input token, so we're also going to need a new recognizer, and
 a  new procedure to read instances of that  token  type.    Let's
 start by defining the two new procedures:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize a Boolean Literal }
 
@@ -372,7 +372,7 @@ end;
 Type  these routines into your program.  You  can  test  them  by
 adding into the main program the print statement
 
-```delphi
+```pascal
    WriteLn(GetBoolean);
 
 ```
@@ -391,7 +391,7 @@ Boolean  NOT.  So now we need to emit the right assembler code to
 load  those  values.    The  first cut at the Boolean  expression
 parser (BoolExpression, of course) is:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Boolean Expression }
 
@@ -423,7 +423,7 @@ since we are keeping to single-character tokens here, I'll encode
 those with '|' and  '~'.  The  next  version of BoolExpression is
 almost a direct copy of the arithmetic procedure Expression:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate a Boolean OR }
 
@@ -465,7 +465,7 @@ end;
 Note the new recognizer  IsOrOp,  which is also a copy, this time
 of IsAddOp:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize a Boolean Orop }
 
@@ -492,7 +492,7 @@ division.
 
 
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Boolean Term }
 
@@ -513,7 +513,7 @@ Now,  we're  almost  home.  We are  translating  complex  Boolean
 expressions, although only for constant values.  The next step is
 to allow for the NOT.  Write the following procedure:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Boolean Factor with NOT }
 
@@ -541,7 +541,7 @@ have  to do that for the Boolean  factor,  because  those  little
 items get taken care of by the next step.  It  takes  just  a one
 line addition to BoolFactor to take care of relations:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Boolean Factor }
 
@@ -572,7 +572,7 @@ checking out what we already have.  So for now let's just write a
 dummy  version  of  Relation  that  does nothing except  eat  the
 current character, and write a little message:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Relation }
 
@@ -603,7 +603,7 @@ below.  Because of the single-character limitation,  I'm sticking
 to the four operators  that  can be encoded with such a character
 (the "not equals" is encoded by '#').
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize a Relop }
 
@@ -674,7 +674,7 @@ anything.
 In  any  case,  we're now ready to look at the code for Relation.
 It's shown below with its companion procedures:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Recognize and Translate a Relational "Equals" }
 
@@ -754,7 +754,7 @@ so  you  may  prefer  to  hold  off  on  that  until you're  sure
 
 everything is working.
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate an Identifier }
 
@@ -967,7 +967,7 @@ SkipWhite, that skips them only in specified "legal" spots.
 
 Here's the procedure:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Skip a CRLF }
 
@@ -982,7 +982,7 @@ end;
 
 Now, add two calls to Fin in procedure Block, like this:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate a Statement Block }
 
@@ -1017,7 +1017,7 @@ Assignment, and add  the  following procedure, copied from one of
 our  earlier  programs.     Note   that   Assignment   now  calls
 BoolExpression, so that we can assign Boolean variables.
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate an Assignment Statement }
 

react-tuto/lbac-markdown/tutor07_lexicalscanning.md

@@ -206,7 +206,7 @@ We  have already dealt with similar  items  in  Installment  III.
 Let's begin (as usual) with a bare cradle.  Not  surprisingly, we
 are going to need a new recognizer:
                               
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize an Alphanumeric Character }
 
@@ -220,7 +220,7 @@ end;
 Using this let's write the following two routines, which are very
 similar to those we've used before:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get an Identifier }
 
@@ -259,7 +259,7 @@ integer as before.)
 
 You  can  easily  verify that these routines work by calling them
 from the main program, as in
-```delphi
+```pascal
      WriteLn(GetName);
 ```
 This  program  will  print any legal name typed in (maximum eight
@@ -275,14 +275,14 @@ We  also  have  dealt with embedded white space before, using the
 two  routines  IsWhite  and  SkipWhite.    Make  sure that  these
 routines are in your  current  version of the cradle, and add the
 the line
-```delphi
+```pascal
      SkipWhite;
 ```
 at the end of both GetName and GetNum.
 
 Now, let's define the new procedure:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Lexical Scanner }
 
@@ -303,7 +303,7 @@ end;
 
 We can call this from the new main program:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 
@@ -393,7 +393,7 @@ To do this, simply modify the single executable  line  of IsWhite
 to read:
 
 
-```delphi
+```pascal
    IsWhite := c in [' ', TAB, CR, LF];
 ```
 
@@ -401,7 +401,7 @@ to read:
 We need to give the main  program  a new stop condition, since it
 will never see a CR.  Let's just use:
 
-```delphi
+```pascal
    until Token = '.';
 
 ```
@@ -446,7 +446,7 @@ it's not in your current version of the cradle, put it there now.
 
 Also, modify the main program to read:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 
@@ -478,7 +478,7 @@ language  to  be  truly  free-field,  then  newlines   should  be
 transparent.   In  this  case,  the  best  approach is to put the
 following lines at the BEGINNING of Scan:
 
-```delphi
+```pascal
 
           while Look = CR do
              Fin;
@@ -490,7 +490,7 @@ comments terminated by newlines),  then  you'll  need for Scan to
 return CR's as tokens.  It  must  also  eat the trailing LF.  The
 best way to do that is to use this line,  again  at the beginning
 of Scan:
-```delphi
+```pascal
           if Look = LF then Fin;
 ```
 
@@ -519,7 +519,7 @@ them if necessary.
 Needless to say, we  can  handle operators very much the same way
 as the other tokens.  Let's start with a recognizer:
                              
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize Any Operator }
 
@@ -540,7 +540,7 @@ course, the list can always be edited.)
 
 Now, let's modify Scan to read:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Lexical Scanner }
 
@@ -584,7 +584,7 @@ I think this is inexcusable.  It's too  easy  to  write  a parser
 that will handle  both  spaces  and  commas  in  a  flexible way.
 Consider the following procedure:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Skip Over a Comma }
 
@@ -682,7 +682,7 @@ because standard Pascal  doesn't  allow  for  arrays  of variable
 lengths.   It's  a  real  bother  to  have to declare a different
 search routine for every table.    Standard  Pascal  also doesn't
 allow for initializing arrays, so you tend to see code like
-```delphi
+```pascal
      Table[1] := 'IF';
      Table[2] := 'ELSE';
      .
@@ -698,7 +698,7 @@ handled with its C-like extensions for pointers.
 
 First, modify your declarations like this:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Type Declarations  }
 
@@ -716,7 +716,7 @@ allocated by the declaration itself,  and the number need only be
 
 Now, just beneath those declarations, add the following:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Definition of Keywords and Token Types }
 
@@ -728,7 +728,7 @@ const KWlist: array [1..4] of Symbol =
 
 Next, insert the following new function:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Table Lookup }
 
@@ -754,7 +754,7 @@ end;
 To test it,  you  can  temporarily  change  the  main  program as
 follows:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 
@@ -779,7 +779,7 @@ So what kind of code should we return?  There are really only two
 reasonable choices.  This seems like an ideal application for the
 Pascal enumerated type.   For  example,  you can define something
 like
-```delphi
+```pascal
      SymType = (IfSym, ElseSym, EndifSym, EndSym, Ident, Number,
                     Operator);
 ```
@@ -788,14 +788,14 @@ try.  Insert the line above into your type definitions.
 
 Now, add the two variable declarations:
                              
-```delphi
+```pascal
     Token: Symtype;          { Current Token  }
     Value: String[16];       { String Token of Look }
 ```
 
 Modify the scanner to read:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Lexical Scanner }
 
@@ -835,7 +835,7 @@ end;
 
 Finally, modify the main program to read:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 
@@ -870,7 +870,7 @@ variables Token and Value, thereby eliminating the  local copies.
 It  also seems a little cleaner to move  the  table  lookup  into
 GetName.  The new form for the four procedures is, then:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get an Identifier }
 
@@ -980,7 +980,7 @@ needing that.  And you can change the type of Token to char.
 
 Next, to replace SymType, add the following constant string:
 
-```delphi
+```pascal
    const KWcode: string[5] = 'xilee';
 ```
 
@@ -989,7 +989,7 @@ Next, to replace SymType, add the following constant string:
 
 Lastly, modify Scan and its relatives as follows:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get an Identifier }
 
@@ -1166,7 +1166,7 @@ I built it by judicious copying of these files,  but  I  wouldn't
 dare try to lead you through that process.  Instead, to avoid any
 confusion, the whole program is shown below:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 program KISS;
 
@@ -1691,7 +1691,7 @@ the following changes:
 
 Here is the program in its entirety:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 program KISS;
                              

react-tuto/lbac-markdown/tutor09_atopview.md

@@ -62,7 +62,7 @@ Whenever  I  start a new design, I always like to do  it  at  the
 absolute beginning.   In  program design language (PDL), this top
 level looks something like:
 
-```delphi
+```pascal
      begin
         solve the problem
      end
@@ -105,7 +105,7 @@ to stand for 'PROGRAM.'
 To a fresh copy of the cradle, add the following code, and insert
 a call to it from the main program:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate A Program }
 
@@ -132,7 +132,7 @@ in this thing too deep to change now!
 Anyhow, SK*DOS is a  particularly  easy OS to interface to.  Here
 is the code for Prolog and Epilog:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Write the Prolog }
 
@@ -181,7 +181,7 @@ does  nothing, then add detail in  incremental  fashion.    Let's
 begin  by  processing  a block, in accordance with its PDL above.
 We can do this in two stages.  First, add the null procedure:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Pascal Block }
 
@@ -193,7 +193,7 @@ end;
 
 and modify Prog to read:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate A Program }
 
@@ -215,7 +215,7 @@ it doesn't.  But now the  definition  of Prog is complete, and we
 can proceed to flesh out DoBlock.  That's done right from its BNF
 definition:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Pascal Block }
 
@@ -268,7 +268,7 @@ must be in a specific order relative to the rest.)
 As  usual,  let's  let a single character represent each of these
 declaration types.  The new form of Declarations is:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate the Declaration Part }
 
@@ -293,7 +293,7 @@ otherwise we'll end up with an infinite While loop.  At  the very
 least, each recognizer must  eat  the  character that invokes it.
 Insert the following procedures:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process Label Statement }
 
@@ -368,7 +368,7 @@ for it is:
 Note that statements can  begin  with  any identifier except END.
 So the first stub form of procedure Statements is:
                               
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate the Statement Part }
 
@@ -511,7 +511,7 @@ Although we're really more interested in full C  here,  I'll show
 you the  code corresponding to this top-level structure for Small
 C.
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate A Program }
 
@@ -574,7 +574,7 @@ declaration is being processed.
 
 To begin, key in the following version of the main program:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 
@@ -602,13 +602,13 @@ to eat input characters until it finds a ^Z.
 Next, let's make  GetClass  do something worthwhile.  Declare the
 global variable
 
-```delphi
+```pascal
      var Class: char;
 ```
 
 and change GetClass to do the following:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 {  Get a Storage Class Specifier }
 
@@ -632,7 +632,7 @@ default class is "auto."
 We  can  do  a  similar  thing  for  types.   Enter the following
 procedure next:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 {  Get a Type Specifier }
 
@@ -669,7 +669,7 @@ can have an initializer.
 
 Insert the following version of TopDecl:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process a Top-Level Declaration }
 
@@ -690,7 +690,7 @@ along to the appropriate routine.)
 
 Finally, add the two procedures DoFunc and DoData:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process a Function Definition }
 

react-tuto/lbac-markdown/tutor10_introducingtiny.md

@@ -135,7 +135,7 @@ Pascal.
 Given  the  BNF  above, let's write a parser that just recognizes
 the brackets:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 {  Parse and Translate a Program }
 
@@ -153,7 +153,7 @@ end;
 The procedure Header just emits  the startup code required by the
 assembler:
                               
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Write Header Info }
 
@@ -167,7 +167,7 @@ end;
 The procedures Prolog and  Epilog  emit  the code for identifying
 the main program, and for returning to the OS:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Write the Prolog }
 
@@ -191,7 +191,7 @@ end;
 The  main program just calls Prog, and then  looks  for  a  clean
 ending:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 
@@ -263,7 +263,7 @@ add or change to your liking, if the language is your own design.
 
 To parse this definition of a main block,  change  procedure Prog
 to read:
-```delphi
+```pascal
 {--------------------------------------------------------------}
 {  Parse and Translate a Program }
 
@@ -279,7 +279,7 @@ end;
 
 and add the new procedure:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Main Program }
 
@@ -295,7 +295,7 @@ end;
 
 Now, the only legal program is:
 
-```delphi
+```pascal
      PROGRAM BEGIN END . (or 'pbe.')
 ```
 
@@ -327,7 +327,7 @@ a type description.
 
 The procedure Prog becomes:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 {  Parse and Translate a Program }
 
@@ -344,7 +344,7 @@ end;
 
 Now, add the two new procedures:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process a Data Declaration }
 
@@ -388,7 +388,7 @@ time we actually produced some code.
 With  a  little  extra  code,  that's  an  easy  thing to do from
 procedure Decl.  Modify it as follows:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Data Declaration }
 
@@ -404,7 +404,7 @@ end;
 The procedure Alloc just  issues  a  command  to the assembler to
 allocate storage:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Allocate Storage for a Variable }
 
@@ -443,7 +443,7 @@ The BNF for `<var-list>` is
 
 Adding this syntax to Decl gives this new version:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Data Declaration }
 
@@ -482,7 +482,7 @@ becomes:
 ```
 Change Alloc as follows:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Allocate Storage for a Variable }
 
@@ -515,7 +515,7 @@ since WriteLn will handle either type.  But there's no  reason to
 limit ourselves  to  single-digit  values  here,  so  the correct
 version to use is the one that returns an integer.  Here it is:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get a Number }
 
@@ -537,7 +537,7 @@ expressions in the data field of the initializer, or at  the very
 least  for  negative  values.  For  now,  let's  just  allow  for
 negative values by changing the code for Alloc as follows:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Allocate Storage for a Variable }
 
@@ -593,13 +593,13 @@ variable names, the symbol table can be trivial.  To  provide for
 it, first add the following  declaration at the beginning of your
 program:
 
-```delphi
+```pascal
      var ST: array['A'..'Z'] of char;
 ```
 
 and insert the following function:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Look for Symbol in Table }
 
@@ -613,7 +613,7 @@ end;
 We  also  need  to initialize the  table  to  all  blanks.    The
 following lines in Init will do the job:
 
-```delphi
+```pascal
 var i: char;
 begin
    for i := 'A' to 'Z' do
@@ -624,7 +624,7 @@ begin
 Finally,  insert  the  following two lines at  the  beginning  of
 Alloc:
 
-```delphi
+```pascal
    if InTable(N) then Abort('Duplicate Variable Name ' + N);
    ST[N] := 'v';
 ```
@@ -663,7 +663,7 @@ assignment statements:
 Let's start things off by adding  a  parser for the block.  We'll
 begin with a stub for the assignment statement:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate an Assignment Statement }
 
@@ -686,7 +686,7 @@ end;
 
 Modify procedure Main to call Block as shown below:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Main Program }
 
@@ -723,7 +723,7 @@ CPU.  The answer, of course, is yes.
 To  accomplish  this,  insert  the  following  "code  generation"
 routines:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Clear the Primary Register }
 
@@ -833,7 +833,7 @@ Note that both LoadVar  and  Store check the symbol table to make
 sure that the variable is defined.  The  error  handler Undefined
 simply calls Abort:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Report an Undefined Identifier }
 
@@ -884,7 +884,7 @@ That's a first for this series.
 
 Anyhow, the following code implements the BNF:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Math Factor }
 
@@ -1068,7 +1068,7 @@ I've added an instruction to sign-extend the low byte.
 
 To begin, we're going to need some more recognizers:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize a Boolean Orop }
 
@@ -1090,7 +1090,7 @@ end;
 
 Also, we're going to need some more code generation routines:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Complement the Primary Register }
 
@@ -1224,7 +1224,7 @@ scanning as well.
 OK, given that we're  all  satisfied  with  the syntax above, the
 corresponding code is shown below:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Recognize and Translate a Relational "Equals" }
 
@@ -1447,7 +1447,7 @@ Use your best judgment as to which way to go.
 OK, with that bit of explanation let's proceed.  As  usual, we're
 going to need some new  code generation routines.  These generate
 the code for conditional and unconditional branches:
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Branch Unconditional  }
 
@@ -1471,7 +1471,7 @@ end;
 Except for the encapsulation of  the code generation, the code to
 parse the control constructs is the same as you've seen before:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Recognize and Translate an IF Construct }
 
@@ -1535,7 +1535,7 @@ where
 ```
 The corresponding code is:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Block of Statements }
 
@@ -1583,7 +1583,7 @@ feel safer taking things one step at a time.
 
 Insert the new procedure:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Skip Over an End-of-Line }
 
@@ -1624,7 +1624,7 @@ If it does, then we're  ready to deal with multi-character tokens
 and keywords.   To begin, add the additional declarations (copied
 almost verbatim from Part VII):
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Type Declarations }
 
@@ -1660,7 +1660,7 @@ const KWcode: string[NKW1] = 'xilewevbep';
 
 Next, add the three procedures, also from Part VII:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Table Lookup }
 
@@ -1705,7 +1705,7 @@ Now, we have to make a  fairly  large number of subtle changes to
 the remaining procedures.  First,  we  must  change  the function
 GetName to a procedure, again as we did in Part VII:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get an Identifier }
 
@@ -1729,7 +1729,7 @@ Value.
 Next, we have to change every reference to GetName to reflect its
 new form. These occur in Factor, Assignment, and Decl:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Math Factor }
 
@@ -1792,7 +1792,7 @@ Mostly, this  involves  deleting  calls  to  Match,  occasionally
 replacing calls to  Match  by calls to MatchString, and Replacing
 calls  to  NewLine  by  calls  to  Scan.    Here are the affected
 routines:
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Recognize and Translate an IF Construct }
 
@@ -1945,13 +1945,13 @@ other fields in separate arrays.
 OK, here are the changes that  need  to  be made.  First, add the
 new typed constant:
 
-```delphi
+```pascal
       NEntry: integer = 0;
 ```
 
 Then change the definition of the symbol table as follows:
 
-```delphi
+```pascal
 const MaxEntry = 100;
 
 var ST   : array[1..MaxEntry] of Symbol;
@@ -1963,7 +1963,7 @@ much RAM space, and so one is never actually allocated.)
 
 Next, we need to replace InTable:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Look for Symbol in Table }
 
@@ -1977,7 +1977,7 @@ end;
 We also need a new procedure, AddEntry, that adds a new  entry to
 the table:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Add a New Entry to Symbol Table }
 
@@ -1994,7 +1994,7 @@ end;
 ```
 This procedure is called by Alloc:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Allocate Storage for a Variable }
 
@@ -2016,7 +2016,7 @@ Assignment, and Decl (just change Value[1] to Value).
 One  last  thing:  change  procedure  Init to clear the array  as
 shown:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Initialize }
 
@@ -2060,7 +2060,7 @@ The changes required affect only the code generation routines and
 procedures Relation and friends.   First, we're going to need two
 more code generation routines:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Set D0 If Compare was <= }
 
@@ -2084,7 +2084,7 @@ end;
 
 Then, modify the relation parsing routines as shown below:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Recognize and Translate a Relational "Less Than or Equal" }
 
@@ -2178,7 +2178,7 @@ As  usual,  for  this we need some more code generation routines.
 These turn out  to be the easiest of all, because all we do is to
 call library procedures to do the work:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Read Variable to Primary Register }
 
@@ -2218,7 +2218,7 @@ just assume that a library call TINYLIB.LIB exists.  Since we now
 need  it  loaded,  we need to add a statement to  include  it  in
 procedure Header:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Write Header Info }
 
@@ -2234,7 +2234,7 @@ That takes care of that part.  Now, we also need to recognize the
 read  and  write  commands.  We can do this by  adding  two  more
 keywords to our list:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Definition of Keywords and Token Types }
 
@@ -2256,7 +2256,7 @@ the 'w' of WHILE.)
 Next, we need procedures for processing the  read/write statement
 and its argument list:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process a Read Statement }
 procedure DoRead;
@@ -2294,7 +2294,7 @@ end;
 Finally,  we  must  expand  procedure  Block  to  handle the  new
 statement types:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Block of Statements }
 
@@ -2346,7 +2346,7 @@ See you then.
 For references purposes, the complete listing of TINY Version 1.0
 is shown below:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 program Tiny10;
 

react-tuto/lbac-markdown/tutor11_lexicalscanrevisit.md

@@ -84,7 +84,7 @@ one day I'd learn: K-I-S-S!
 The problem begins to show  itself in procedure Block, which I've
 reproduced below:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Block of Statements }
 
@@ -166,7 +166,7 @@ than we've had to deal with in the past.
 
 Let's  begin  to  fix  the  problem  by  re-introducing  the  two
 procedures:
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get an Identifier }
 
@@ -210,7 +210,7 @@ the first character NOT part of the token.
 We  can do the same thing  for  operators,  even  multi-character
 operators, with a procedure such as:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get an Operator }
 
@@ -235,7 +235,7 @@ that can handle all three  cases.  The  following  procedure will
 read any one of the token types and always leave the input stream
 advanced beyond it:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get the Next Input Token }
 
@@ -274,7 +274,7 @@ the concepts, by treating CR and LF as whitespace characters, and
 eliminating NewLine.  You  can  do  that  simply by modifying the
 function IsWhite:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize White Space }
 
@@ -289,7 +289,7 @@ We've already tried similar routines in Part VII,  but  you might
 as well try these new ones out.  Add them to a copy of the Cradle
 and call Next with the following main program:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 
@@ -331,7 +331,7 @@ were treating them as special cases anyway.
 
 So here's the final version of GetOp:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get an Operator }
 
@@ -371,7 +371,7 @@ version of Scan shown below  does NOTHING but check for keywords.
 Notice that it operates on the current token and does NOT advance
 the input stream.
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Scan the Current Identifier for Keywords }
 
@@ -395,7 +395,7 @@ The  following  version  of MatchString takes the  place  of  the
 character-oriented Match.  Note that, like Match, it DOES advance
 the input stream.
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Match a Specific Input String }
 
@@ -419,7 +419,7 @@ the general idea and then just give the finished product.
 First of all, the code for procedure Block doesn't change, though
 its function does:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Block of Statements }
 
@@ -447,7 +447,7 @@ advanced by each procedure that Block calls.
 In general, we have to replace every test on Look with  a similar
 test on Token.  For example:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Boolean Expression }
 
@@ -468,7 +468,7 @@ end;
 In procedures like Add, we don't  have  to use Match anymore.  We
 need only call Next to advance the input stream:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize and Translate an Add }
 
@@ -484,7 +484,7 @@ end;
 Control  structures  are  actually simpler.  We just call Next to
 advance over the control keywords:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Recognize and Translate an IF Construct }
 
@@ -576,7 +576,7 @@ getting very close to being able to write a serious compiler.
 
 ## TINY VERSION 1.1
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 program Tiny11;
 

react-tuto/lbac-markdown/tutor12_miscellany.md

@@ -259,7 +259,7 @@ parser.  Let's take the last case first, since it's simpler.
 
 To begin, I've made things easy by introducing a new recognizer:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Match a Semicolon }
 
@@ -277,7 +277,7 @@ to the next one.
 Since a  semicolon follows a statement, procedure Block is almost
 the only one we need to change:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Block of Statements }
 
@@ -307,7 +307,7 @@ could happen if the statement is null).
 Since declarations are also  statements,  we  also  need to add a
 call to Semi within procedure TopDecls:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate Global Declarations }
 
@@ -326,7 +326,7 @@ end;
 
 Finally, we need one for the PROGRAM statement:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 
@@ -353,7 +353,7 @@ requires  minor  changes,  and those only to procedure Block.  To
 keep things as simple as possible, let's split the procedure into
 two parts.  The following procedure handles just one statement:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Single Statement }
 
@@ -373,7 +373,7 @@ end;
 
 Using this procedure, we can now rewrite Block like this:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Block of Statements }
 
@@ -404,7 +404,7 @@ So I have what I think is a nice compromise: Make them OPTIONAL!
 
 Consider the following version of Semi:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Match a Semicolon }
 
@@ -458,7 +458,7 @@ experiments with a working copy.)
 Now, we're going to need a  procedure  to skip over comments.  So
 key in the following one:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Skip A Comment Field }
 
@@ -479,7 +479,7 @@ Look.
 Now we can  write  a  new  version of GetChar that SkipComment to
 strip out comments:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get Character from Input Stream }
 { Skip Any Comments }
@@ -523,7 +523,7 @@ To  do  this,  first change GetChar back to the way  it  was  and
 change the name called in SkipComment.  Then, let's add  the left
 brace as a possible whitespace character:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize White Space }
 
@@ -536,7 +536,7 @@ end;
 
 Now, we can deal with comments in procedure SkipWhite:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Skip Over Leading White Space }
 
@@ -569,7 +569,7 @@ here won't allow that and, again, neither will Turbo Pascal.
 But the fix is incredibly easy.  All  we  need  to  do is to make
 SkipComment recursive:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Skip A Comment Field }
 
@@ -606,7 +606,7 @@ we  need  to  go back to the "GetCharX' approach.  In yet another
 copy of your compiler, rename  GetChar to GetCharX and then enter
 the following new procedure GetChar:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Read New Character.  Intercept '/*' }
 
@@ -647,13 +647,13 @@ Note that you need to declare this new variable and initialize it
 to ' '.  I like to do  things  like  that  using the Turbo "typed
 constant" construct:
 
-```delphi
+```pascal
      const TempChar: char = ' ';
 
 ```
 Now we need a new version of SkipComment:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Skip A Comment Field }
 
@@ -695,7 +695,7 @@ are terminated by the end of the line.  In a  way,  that  case is
 easier.   The only procedure that would need  to  be  changed  is
 SkipComment, which must now terminate at the newline characters:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Skip A Comment Field }
 

react-tuto/lbac-markdown/tutor13_procedures.md

@@ -144,7 +144,7 @@ Most of the program  is  just the standard Cradle routines.  I've
 shown the whole thing here, just to make sure we're  all starting
 from the same point:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 program Calls;
 
@@ -585,7 +585,7 @@ have no parameter lists.
 As a start, let's consider a simple program with a procedure, and
 think about the code we'd like to see generated for it:
 
-```delphi
+```pascal
      PROGRAM FOO;
      .
      .
@@ -616,7 +616,7 @@ that  although a procedure may be quite  long,  declaring  it  is
 really no different than  declaring  a  variable.   It's just one
 more kind of declaration.  We can write the BNF:
 
-```delphi
+```pascal
      <declaration> ::= <data decl> | <procedure>
 ```
 
@@ -624,7 +624,7 @@ This means that it should be easy to modify TopDecl to  deal with
 procedures.  What about the syntax of a procedure?   Well, here's
 a suggested syntax, which is essentially that of Pascal:
 
-```delphi
+```pascal
      <procedure> ::= PROCEDURE <ident> <begin-block>
 ```
 
@@ -633,7 +633,7 @@ generated within the begin-block.    We need only emit a label at
 the beginning of the procedure, and an RTS at the end.
 
 Here's the required code:
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Procedure Declaration }
 
@@ -659,7 +659,7 @@ merely emits an RTS instruction.  The creation of that routine is
 To  finish  this  version, add the following line within the Case
 statement in DoBlock:
 
-```delphi
+```pascal
             'p': DoProc;
 ```
 
@@ -671,7 +671,7 @@ labels,   constants,  types,  variables,  procedures,  and   main
 program.  To  follow  such  a  scheme, we should separate the two
 declarations, and have code in the main program something like
 
-```delphi
+```pascal
      DoVars;
      DoProcs;
      DoMain;
@@ -708,7 +708,7 @@ Before going on to the next step, it's also worth noting that the
 "main program" as it stands  is incomplete, since it doesn't have
 the label and END statement.  Let's fix that little oversight:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Main Program }
 
@@ -762,7 +762,7 @@ programmers, and for big Pascal programs sometimes it's difficult
 to  find the beginning of the main program at all.  This leads to
 conventions such as identifying it in comments:
 
-```delphi
+```pascal
      BEGIN { of MAIN }
 
 ```
@@ -792,7 +792,7 @@ it, as in Pascal).  In this case, our BNF becomes:
 The code  also  looks  much  better,  at  least in the sense that
 DoMain and DoProc look more alike:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Main Program }
 
@@ -894,7 +894,7 @@ parsing rule can be easily handled as a special case.
 
 Here's how to do it:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate an Assignment Statement }
 
@@ -944,7 +944,7 @@ already been read,  we  must  pass  it to the two procedures, and
 modify Assignment to match.   Procedure CallProc is a simple code
 generation routine:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Call a Procedure }
 
@@ -1015,7 +1015,7 @@ view.  But to tell the truth I prefer the latter.  For procedures
 alone, the  decision would seem to favor the "listless" approach.
 The statement
 
-```delphi
+```pascal
      Initialize; ,
 
 ```
@@ -1050,7 +1050,7 @@ extra code ... just parse the syntax.  The  code  for  processing
 the declaration has very  much  the  same  form we've seen before
 when dealing with VAR-lists:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process the Formal Parameter List of a Procedure }
 
@@ -1071,7 +1071,7 @@ end;
 
 Procedure DoProc needs to have a line added to call FormalList:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Procedure Declaration }
 
@@ -1094,7 +1094,7 @@ end;
 For now, the code for FormalParam is just a dummy one that simply
 skips the parameter name:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process a Formal Parameter }
 
@@ -1109,7 +1109,7 @@ end;
 For  the actual procedure call, there must  be  similar  code  to
 process the actual parameter list:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process an Actual Parameter }
 
@@ -1217,7 +1217,7 @@ a bad convergence of several implementation decisions.
 
 Suppose we have a subroutine:
 
-```delphi
+```pascal
      SUBROUTINE FOO(X, Y, N)
 ```
 
@@ -1225,7 +1225,7 @@ where N is some kind of  input  count  or flag.  Many times, we'd
 like  to be able to pass a literal or even an expression in place
 of a variable, such as:
 
-```delphi
+```pascal
      CALL FOO(A, B, J + 1)
 ```
 
@@ -1233,7 +1233,7 @@ Here the third  parameter  is  not  a  variable, and so it has no
 address.    The  earliest FORTRAN compilers did  not  allow  such
 things, so we had to resort to subterfuges like:
 
-```delphi
+```pascal
      K = J + 1
      CALL FOO(A, B, K)
 ```
@@ -1254,7 +1254,7 @@ The  problem  arose  when  someone  decided to make  things  more
 efficient.  They  reasoned,  rightly enough, that the most common
 kind of "expression" was a single integer value, as in:
 
-```delphi
+```pascal
      CALL FOO(A, B, 4)
 ```
 
@@ -1355,7 +1355,7 @@ Let's just try some simple-minded  things and see where they lead
 us.    Let's begin with the pass-by-value  case.    Consider  the
 procedure call:
 
-```delphi
+```pascal
      FOO(X, Y)
 ```
 
@@ -1393,7 +1393,7 @@ are:
 
 Now consider what the called procedure might look like:
 
-```delphi
+```pascal
      PROCEDURE FOO(A, B)
      BEGIN
           A = B
@@ -1418,14 +1418,14 @@ table for the formal parameters.
 
 Let's begin by declaring a new table:
 
-```delphi
+```pascal
      var Params: Array['A'..'Z'] of integer;
 ```
 
 We  also  will  need to keep track of how many parameters a given
 procedure has:
 
-```delphi
+```pascal
      var NumParams: integer;
 ```
 
@@ -1434,7 +1434,7 @@ formal parameter list  will  be different for each procedure that
 we process, so we'll need to initialize that table anew  for each
 procedure.  Here's the initializer:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Initialize Parameter Table to Null }
 
@@ -1451,7 +1451,7 @@ end;
 We'll put a call to this procedure in Init, and  also  at the end
 of DoProc:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Initialize }
 
@@ -1496,7 +1496,7 @@ OK, now  we  need  a  few procedures to work with the table.  The
 next few functions are  essentially  copies  of  InTable, TypeOf,
 etc.:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Find the Parameter Number }
 
@@ -1529,7 +1529,7 @@ end;
 
 Finally, we need some code generation routines:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Load a Parameter to the Primary Register }
 
@@ -1574,7 +1574,7 @@ deal with the syntax is already in place).
 Let's begin by processing a formal parameter.  All we have  to do
 is to add each parameter to the parameter symbol table:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process a Formal Parameter }
 
@@ -1590,7 +1590,7 @@ in the body of the procedure?  That takes a little more work.  We
 must first determine that it IS a formal parameter.  To  do this,
 I've written a modified version of TypeOf:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get Type of Symbol }
 
@@ -1609,7 +1609,7 @@ relocated in your source.)
 
 We also must modify AssignOrProc to deal with this new type:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Decide if a Statement is an Assignment or Procedure Call }
 
@@ -1631,7 +1631,7 @@ end;
 Finally,  the  code  to process an assignment  statement  and  an
 expression must be extended:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate an Expression }
 { Vestigial Version }
@@ -1672,7 +1672,7 @@ have to be added to Factor, not Expression.
 The rest is easy.  We need only add the  semantics  to the actual
 procedure call, which we can do with one new line of code:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process an Actual Parameter }
 
@@ -1730,7 +1730,7 @@ items  it  pushed.    To  make  things  easy, I've  modified  the
 procedure  ParamList to be a function  instead  of  a  procedure,
 returning the number of bytes pushed:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process the Parameter List for a Procedure  Call }
 
@@ -1756,7 +1756,7 @@ end;
 
 Procedure CallProc then uses this to clean up the stack:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process a Procedure Call }
 
@@ -1772,7 +1772,7 @@ end;
 
 Here I've created yet another code generation procedure:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Adjust the Stack Pointer Upwards by N Bytes }
 
@@ -1794,7 +1794,7 @@ the stack pointer.  That works fine in our simple examples, since
 with our rudimentary  form  of expressions nobody else is messing
 with the stack.  But consider a different example as simple as:
 
-```delphi
+```pascal
      PROCEDURE FOO(A, B)
      BEGIN
           A = A + B
@@ -1865,7 +1865,7 @@ generation created by DoProc.  Since that makes the code a little
 more than one line, I've created new procedures to deal  with it,
 paralleling the Prolog and Epilog procedures called by DoMain:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Write the Prolog for a Procedure }
 
@@ -1889,7 +1889,7 @@ end;
 
 Procedure DoProc now just calls these:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Procedure Declaration }
 
@@ -1913,7 +1913,7 @@ end;
 Finally, we need to  change  the  references  to SP in procedures
 LoadParam and StoreParam:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Load a Parameter to the Primary Register }
 
@@ -1981,13 +1981,13 @@ again later.
 Let's begin by looking at the code we'd like to see generated for
 the new case. Using the same example as before, we need the call
 
-```delphi
+```pascal
      FOO(X, Y)
 ```
 
 to be translated to:
 
-```delphi
+```pascal
      PEA X(PC)           ; Push the address of X
      PEA Y(PC)           ; Push Y the address of Y
      BSR FOO             ; Call FOO
@@ -1995,7 +1995,7 @@ to be translated to:
 
 That's a simple matter of a slight change to Param:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process an Actual Parameter }
 
@@ -2029,7 +2029,7 @@ given one level of indirection:
 All  of  this  can  be   handled  by  changes  to  LoadParam  and
 StoreParam:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Load a Parameter to the Primary Register }
 
@@ -2059,7 +2059,7 @@ end;
 To  get  the  count  right,  we  must  also  change  one line  in
 ParamList:
 
-```delphi
+```pascal
      ParamList := 4 * N;
 ```
 
@@ -2175,14 +2175,14 @@ the whole thing.
 
 Let's start by creating a new variable, Base:
 
-```delphi
+```pascal
      var Base: integer;
 ```
 We'll use this  variable,  instead of NumParams, to compute stack
 offsets.  That means changing  the two references to NumParams in
 LoadParam and StoreParam:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Load a Parameter to the Primary Register }
 
@@ -2213,7 +2213,7 @@ processed the formal parameters, and  won't  increase  further as
 the new, local variables, are inserted in the symbol table.  This
 is taken care of at the end of FormalList:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Process the Formal Parameter List of a Procedure }
 
@@ -2243,7 +2243,7 @@ About all we  need  to  do  next  is to install the semantics for
 declaring local variables into the parser.  The routines are very
 similar to Decl and TopDecls:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Local Data Declaration }
 
@@ -2279,7 +2279,7 @@ to DoProc.
 
 Next, we modify DoProc to use this information:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Procedure Declaration }
 
@@ -2311,7 +2311,7 @@ Note the change in the call  to  ProcProlog.  The new argument is
 the number of WORDS (not bytes) to allocate space  for.    Here's
 the new version of ProcProlog:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Write the Prolog for a Procedure }
 

react-tuto/lbac-markdown/tutor14_types.md

@@ -145,7 +145,7 @@ deal with it, we'll steal some procedures that we've used before.
 
 First, we need to declare the symbol table itself:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Variable Declarations }
 
@@ -158,7 +158,7 @@ var Look: char;              { Lookahead Character }
 Next, we need to make sure it's initialized as part  of procedure
 Init:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Initialize }
 
@@ -176,7 +176,7 @@ We don't really need  the  next procedure, but it will be helpful
 for debugging.  All it does is to dump the contents of the symbol
 table:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Dump the Symbol Table }
 
@@ -200,7 +200,7 @@ here, I'm reproducing the entire program below, complete with the
 new  procedures.  Note that this  version  includes  support  for
 white space:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 program Types;
 
@@ -449,7 +449,7 @@ Of course, in general we  only  want  to  see  the  types  of the
 variables that have been defined.  We can eliminate the others by
 modifying DumpTable with an IF test.  Change the loop to read:
 
-```delphi
+```pascal
   for i := 'A' to 'Z' do
      if ST[i] <> '?' then
          WriteLn(i, ' ', ST[i]);
@@ -462,7 +462,7 @@ at all, since at this point NONE of the names have been declared.
 We  can  spice  things up a  bit  by  inserting  some  statements
 declaring some entries in the main program.  Try these:
 
-```delphi
+```pascal
      ST['A'] := 'a';
      ST['P'] := 'b';
      ST['X'] := 'c';
@@ -482,7 +482,7 @@ aren't redeclaring a variable that's already in use  (easy  to do
 with only 26 choices!).  To handle all this, enter  the following
 new procedures:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Report Type of a Variable }
 
@@ -525,7 +525,7 @@ end;
 
 Now change the three lines in the main program to read:
 
-```delphi
+```pascal
      AddEntry('A', 'a');
      AddEntry('P', 'b');
      AddEntry('X', 'c');
@@ -556,7 +556,7 @@ variable lists and  initializers.   In procedure Alloc, note that
 the  new call to AddEntry will also  take  care  of  checking for
 duplicate declarations:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Allocate Storage for a Variable }
 
@@ -633,7 +633,7 @@ separated  the  code  generation parts of Alloc  from  the  logic
 parts.  This  is  in  keeping  with our desire to encapsulate the
 machine-dependent part of the compiler.
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Generate Code for Allocation of a Variable }
 
@@ -699,7 +699,7 @@ Alloc; that is, make a load procedure that can load more than one
 size.    We  also  want  to continue to encapsulate the  machine-
 dependent stuff.  The load procedure looks like this:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Load a Variable to Primary Register }
 
@@ -715,7 +715,7 @@ out to be MOVE's.  It turns out to be useful to create a separate
 code generator just for these instructions, and then  call  it as
 needed:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Generate a Move Instruction }
 
@@ -734,7 +734,7 @@ First of all, we need to make sure that the  type  we are dealing
 with is a  loadable  type.    This  sounds like a job for another
 recognizer:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Recognize a Legal Variable Type }
 
@@ -749,7 +749,7 @@ Next, it would be nice to have a routine that will fetch the type
 of a variable from the symbol table, while checking  it  to  make
 sure it's valid:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get a Variable Type from the Symbol Table }
 
@@ -767,7 +767,7 @@ end;
 Armed with these  tools,  a  procedure  to cause a variable to be
 loaded becomes trivial:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Load a Variable to the Primary Register }
 
@@ -791,7 +791,7 @@ It would be a good idea to test the program at this point.  Since
 we don't have a  procedure  for  dealing  with assignments yet, I
 just added the lines:
 
-```delphi
+```pascal
      Load('A');
      Load('B');
      Load('C');
@@ -807,7 +807,7 @@ I'm sure you won't be surprised to learn  that  storing variables
 is a lot like  loading  them.  The necessary procedures are shown
 next:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Store Primary to Variable }
 
@@ -836,7 +836,7 @@ version   of  procedure  Block  that  supports  only   assignment
 statements, and also a  special  version  of Expression that only
 supports single variables as legal expressions.  Here they are:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate an Expression }
 
@@ -892,7 +892,7 @@ everything will be fine.
 Now, we can  complete  the  task  by changing the main program to
 read:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Main Program }
 
@@ -939,7 +939,7 @@ WRONG!
 
 Look at the code for a=c above.  The code is:
 
-```delphi
+```pascal
      MOVE.L    C(PC),D0
      LEA       A(PC),A0
      MOVE.B    D0,(A0)
@@ -991,7 +991,7 @@ This takes the addition of only one line to LoadVar,  although if
 we  are  not  going to COMPLETELY ignore efficiency, it should be
 guarded by an IF test.  Here is the modified version:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Load a Variable to Primary Register }
 
@@ -1030,7 +1030,7 @@ should do a  sign  extension  after  the load, instead of a clear
 before it. Just  to  tie  this  part  of the discussion up with a
 nice, red ribbon, let's change LoadVar as shown below:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Load a Variable to Primary Register }
 
@@ -1083,7 +1083,7 @@ mods, like the method, are quite simple.  First of all,  since we
 aren't requiring LoadVar to do  all the work of conversion, let's
 go back to the simple version:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Load a Variable to Primary Register }
 
@@ -1097,7 +1097,7 @@ end;
 Next, let's add a  new  procedure that will convert from one type
 to another:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Convert a Data Item from One Type to Another }
 
@@ -1117,7 +1117,7 @@ end;
 Next, we need to do  the  logic  required  to  load  and  store a
 variable of any type.  Here are the routines for that:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Load a Variable to the Primary Register }
 
@@ -1155,7 +1155,7 @@ rudimentary   assignment   statement  is   essentially   trivial.
 Procedure Expression now becomes a  function,  which  returns its
 type to procedure Assignment:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate an Expression }
 
@@ -1212,7 +1212,7 @@ LongInt, so that it can handle anything we  throw  at  it.   Note
 that no type information is returned here: GetNum doesn't concern
 itself with how the number will be used:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get a Number }
 
@@ -1245,7 +1245,7 @@ well.
 A better approach is to select a type based upon the value of the
 literal, as shown next:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Load a Constant to the Primary Register }
 
@@ -1272,7 +1272,7 @@ Note  that  LoadNum  calls  a  new version of the code  generator
 routine  LoadConst, which has an added  argument  to  define  the
 type:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Load a Constant to the Primary Register }
 
@@ -1288,7 +1288,7 @@ end;
 Now  we can modify procedure Expression  to  accomodate  the  two
 possible kinds of factors:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate an Expression }
 
@@ -1327,7 +1327,7 @@ The  first  step  is  easy:  We can rename our existing  function
 Expression  to  Term,  as  we've  done so many times before,  and
 create the new version of Expression:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate an Expression }
 
@@ -1365,7 +1365,7 @@ issues.
 For  this  version,  though, we'll retain the same dumb old code,
 which makes the new routine trivial:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Process a Term with Leading Unary Operator }
 
@@ -1380,7 +1380,7 @@ end;
 Procedure  Push  is  a code-generator routine, and now has a type
 argument:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Push Primary onto Stack }
 
@@ -1396,7 +1396,7 @@ older versions of these routines, we let them call code generator
 routines PopAdd and PopSub.    We'll  continue  to do that, which
 makes the functions themselves extremely simple:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Recognize and Translate an Add }
 
@@ -1446,7 +1446,7 @@ The  first  step in this new structure  is  to  introduce  a  Pop
 procedure analogous to the Push.   This procedure will always Pop
 the top element of the stack into D7:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Pop Stack into Secondary Register }
 
@@ -1463,7 +1463,7 @@ registers, so we can promote whichever  one  we need to.  To deal
 with this, procedure Convert needs another argument, the register
 name:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Convert a Data Item from One Type to Another }
 
@@ -1484,7 +1484,7 @@ T1  is  smaller  in size than the desired  type  T2.    It  is  a
 function, returning the final type to let us know what it decided
 to do:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Promote the Size of a Register Value }
 
@@ -1505,7 +1505,7 @@ end;
 Finally, the following function forces the two registers to be of
 the same type:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Force both Arguments to Same Type }
 
@@ -1520,7 +1520,7 @@ end;
 These new routines give us the ammunition we need  to  flesh  out
 PopAdd and PopSub:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Generate Code to Add Primary to the Stack }
 
@@ -1557,7 +1557,7 @@ are vestigial forms of the ORIGINAL PopAdd and PopSub.   That is,
 they  are pure code generators, producing a  register-to-register
 add or subtract:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Add Top of Stack to Primary }
 
@@ -1622,7 +1622,7 @@ identical, so I'll just show them here without much fanfare.  The
 first  one  is  our  general  form  for  Factor,  which  includes
 parenthetical subexpressions:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Parse and Translate a Factor }
 
@@ -1761,7 +1761,7 @@ Now, clearly, we are going to have to generate different code for
 the 16-bit and 32-bit multiplies.  This is best  done  by  having
 separate code generator routines for the two cases:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Multiply Top of Stack by Primary (Word) }
 
@@ -1784,7 +1784,7 @@ end;
 An examination of the code below for PopMul  should  convince you
 that the conditions in the table are met:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Generate Code to Multiply Primary by Stack }
 
@@ -1900,7 +1900,7 @@ the lower word of the divisor.)
 
 The following code provides the correct function for PopDiv:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Generate Code to Divide Stack by the Primary }
 
@@ -1924,7 +1924,7 @@ end;
 
 The two code generation procedures are:
 
-```delphi
+```pascal
 {---------------------------------------------------------------}
 { Divide Top of Stack by Primary  (Word) }
 

react-tuto/lbac-markdown/tutor15_backtothefuture.md

@@ -204,7 +204,7 @@ our approach is simpler). We'll begin our hike into the future by
 translating this concept into our new, unit-based organization.  
 The first unit, appropriately called Input, is shown below:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 unit Input;
 {--------------------------------------------------------------}
@@ -249,7 +249,7 @@ the software, of course, we always need a main program.  I used
 the following, really complex test program, which we'll later 
 evolve into the Main for our compiler:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 program Main;
 uses WinCRT, Input;
@@ -313,7 +313,7 @@ Of course, every decent program should have output, and ours is no
 exception.  Our output routines included the Emit functions.  The 
 code for the corresponding output unit is shown next:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 unit Output;
 {--------------------------------------------------------------}
@@ -350,7 +350,7 @@ end.
 no begin-block.)
  
 Test this unit with the following main program:
-```delphi
+```pascal
 {--------------------------------------------------------------}
 program Test;
 uses WinCRT, Input, Output, Scanner, Parser;
@@ -382,11 +382,11 @@ instructions starting there.  So, at the very least, we must space
 the instructions over one column to keep the assembler happy.  .  
 That's easy enough to do:  Simply change, in procedure Emit, the 
 line:
-```delphi
+```pascal
 	Write(TAB, s);
 ```
 by:
-```delphi
+```pascal
 	Write(' ', s);
 ```
 I must admit that I've wrestled with this problem before, and find 
@@ -455,7 +455,7 @@ we ever found a use for the procedure that didn't halt, so in the
 new, lean and mean unit Errors, shown next, procedure Error takes 
 the place of Abort.
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 unit Errors;
 {--------------------------------------------------------------}
@@ -492,7 +492,7 @@ As usual, here's a test program:
 
 
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 program Test;
 uses WinCRT, Input, Output, Errors;
@@ -557,7 +557,7 @@ both.  I've created two versions of the Scanner unit.  The first
 one, called Scanner1, contains the single-digit version of the 
 recognizers:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 unit Scanner1;
 {--------------------------------------------------------------}
@@ -654,7 +654,7 @@ The following code fragment of the main program provides a good
 test of the scanner.  For brevity, I'll only include the 
 executable code here; the rest remains the same.  Don't forget, 
 though, to add the name Scanner1 to the "uses" clause.
-```delphi
+```pascal
 	Write(GetName);
 	Match('=');
 	Write(GetNumber);
@@ -680,7 +680,7 @@ GetNumber, change between the two units, but just to be sure there
 are no mistakes, I've reproduced the entire unit here.  This is 
 unit Scanner:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 unit Scanner;
 {--------------------------------------------------------------}
@@ -867,7 +867,7 @@ as simple as that.
 For those of you who still think we may need the integer version 
 (and indeed we may), here it is:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Get a Number (integer version) }
 
@@ -916,7 +916,7 @@ and then for a factor that could be either constant or variable.
 For old times sake, let's revisit that process.  Define the 
 following new unit:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 unit Parser;
 {--------------------------------------------------------------}
@@ -956,7 +956,7 @@ replace CodeGen with one suitable for your CPU of choice.
 So far, our code generator has only one procedure in it.  Here's 
 the unit:
 
-```delphi
+```pascal
 {--------------------------------------------------------------}
 unit CodeGen;
 
@@ -1006,7 +1006,7 @@ that in the next installment, but before I close, let's finish out
 the parsing of a factor, just to satisfy ourselves that we still 
 know how.  The final version of CodeGen includes the new 
 procedure, LoadVariable:
-```delphi
+```pascal
 {--------------------------------------------------------------}
 unit CodeGen;
 
@@ -1042,7 +1042,7 @@ end.
 
 The parser unit itself doesn't change, but we have a more complex 
 version of procedure Factor:
-```delphi
+```pascal
 {--------------------------------------------------------------}
 { Parse and Translate a Factor }
 

react-tuto/lbac-markdown/tutor16_unitconstruction.md

@@ -267,7 +267,7 @@ current version of procedure Factor, as we left it in Installment 15,
 can't handle negative arguments.  To fix that, we'll introduce the 
 procedure SignedFactor: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Parse and Translate a Factor with Optional Sign } 
  
@@ -285,7 +285,7 @@ end;
  
 Note that this procedure calls a new code generation routine, Negate: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Negate Primary } 
  
@@ -329,7 +329,7 @@ system.
  
 For the record, one of my standard tests for any new compiler is to see 
 how the compiler deals with a null program like: 
-```delphi
+```pascal
 	program main; 
 	begin 
 	end. 
@@ -373,7 +373,7 @@ and consider only expressions with additive terms in them.  The
 code to implement expressions, including a possibly signed first 
 term, is shown next: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Parse and Translate an Expression } 
  
@@ -392,7 +392,7 @@ end;
 This procedure calls two other procedures to process the 
 operations: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Parse and Translate an Addition Operation } 
  
@@ -426,7 +426,7 @@ subtract it from, the primary register.  The code is shown next:
  
  
 
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Push Primary to Stack } 
  
@@ -462,7 +462,7 @@ multiplicative terms.  To that end, we'll add a procedure Term, and code
 generation procedures PopMul and PopDiv.  These code generation 
 procedures are shown next: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Multiply TOS by Primary } 
  
@@ -498,7 +498,7 @@ multiple data types, type conversions, etc.
 Our procedure Term is virtually a clone of Expression, and looks like 
 this: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Parse and Translate a Term } 
  
@@ -518,7 +518,7 @@ Our next step is to change some names.  SignedFactor now becomes
 SignedTerm, and the calls to Factor in Expression, Add, Subtract and 
 SignedTerm get changed to call Term: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Parse and Translate a Term with Optional Leading Sign } 
  
@@ -566,7 +566,7 @@ procedure Factor to allow for parenthetical expressions.  By using a
 recursive call to Expression, we can reduce the needed code to virtually 
 nothing.  Five lines added to Factor do the job: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Parse and Translate a Factor } 
  
@@ -599,7 +599,7 @@ of the target variable where we are to store the result of an
 expression, call Expression, then store the number.  The procedure is 
 shown next: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Parse and Translate an Assignment Statement } 
  
@@ -615,7 +615,7 @@ end;
 ```
 The assignment calls for yet another code generation routine: 
  
-```delphi
+```pascal
 
 {--------------------------------------------------------------} 
 { Store the Primary Register to a Variable } 
@@ -660,7 +660,7 @@ expressions, paralleling in most details the arithmetic expressions, but
 at a different precedence level.  All of this, as it turned out, came 
 about because I didn't like having to put parentheses around the Boolean 
 expressions in statements like: 
-```delphi
+```pascal
 IF (c >= 'A') and (c <= 'Z') then ... 
 ```
 In retrospect, that seems a pretty petty reason to add many layers of 
@@ -677,7 +677,7 @@ That's easily done; first, modify the function IsAddop in unit Scanner
 to include two extra operators: '|' for "or," and '~' for "exclusive 
 or": 
 
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 function IsAddop(c: char): boolean; 
 begin 
@@ -689,7 +689,7 @@ end;
 Next, we must include the parsing of the operators in procedure 
 Expression: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 procedure Expression; 
 begin 
@@ -710,7 +710,7 @@ reserved words in Turbo Pascal.)
  
 Next, the procedures _Or and _Xor: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Parse and Translate a Subtraction Operation } 
  
@@ -736,7 +736,7 @@ end;
 ```
 And, finally, the new code generator procedures: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Or TOS with Primary } 
  
@@ -859,7 +859,7 @@ With that bit of philosophy out of the way, we can press on to the
 probably do this without me, but here's the code, anyway: 
  
 In Scanner, 
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 function IsMulop(c: char): boolean; 
 begin 
@@ -869,7 +869,7 @@ end;
 ```
 In Parser, 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 procedure Term; 
 begin 
@@ -896,7 +896,7 @@ end;
 ```
 and in CodeGen, 
  
-```delphi 
+```pascal 
 {--------------------------------------------------------------} 
 { And Primary with TOS } 
  
@@ -981,7 +981,7 @@ So how do we mechanize the rules?  In the same way as we did with
 SignedTerm, but at the factor level.  We'll define a procedure 
 `NotFactor`: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Parse and Translate a Factor with Optional "Not" } 
  
@@ -1002,7 +1002,7 @@ and call it from all the places where we formerly called Factor, i.e.,
 from Term, Multiply, Divide, and _And.  Note the new code generation 
 procedure: 
  
-```delphi
+```pascal
 {--------------------------------------------------------------} 
 { Bitwise Not Primary } 
  

react-tuto/tools/extractAll.js

@@ -9,6 +9,7 @@ const writeFileAsync = promisify(fs.writeFile);
 
 if (!process.env.MD_PATH) {
   console.log('process.env.MD_PATH must be defined');
+  process.exit(1);
 }
 const markdownPath = path.join(process.cwd(), process.env.MD_PATH);