1. Project 1: Part b SPECIFICATION
COS341, 2017
Project 1: Part b
SPECIFICATION
Note:
During the whole of Project 1 (also now in 1b) you cooperate with the same project partner.
Only in the follow-up Project 2, a new project partner will be allocated to you.

2. Preliminaries
It is herewith presumed that you have already completed the previous Part a of this Project 1 (together with your project partner )
The output file from 1a will now serve as input file for Part b of this project.
Input .txt
LINKED
LIST
DATA
FILE
Project 1a
Project 1b
...

3. Students’ Programming Language: SPL
In Project 1 we deal with SPL, which your professor has “created” for you (for educational purposes).
In Part 1a we already dealt with the lexical analysis of SPL.
In Part 1b (now) we deal with the syntax analysis (grammar and parsing) of SPL.
On the following slides,
the syntactic structure of SPL will be given,
and your assignment task will be stipulated.

4. The Grammar
of SPL

5. Notation On the following slides,
the RED CAPITAL LETTERS indicate the non-terminal symbols in the grammar of SPL
the arrows  separate the Left-hand-sides and the Right-hand-sides of the grammar’s rules,
the blue bold text indicates the terminal symbols in the vocabulary of SPL (from Part a: “lexing”),
normal text (like this) provides explanations and stipulates the project task which you will have to carry out.

6. PROC_DEFS  PROC PROC_DEFS PROC  proc UserDefinedName { PROG }
PROG  CODE
PROG  CODE ; PROC_DEFS
PROC_DEFS  PROC
PROC_DEFS  PROC PROC_DEFS
PROC  proc UserDefinedName
{ PROG }
CODE  INSTR
CODE  INSTR ; CODE
Note: the UserDefinedName
comes from the token class
on slide 8 of project Part 1a !

7. CALL  UserDefinedName
INSTR  halt
INSTR  IO
INSTR  CALL
INSTR  ASSIGN
INSTR  COND_BRANCH
INSTR  COND_LOOP
IO  input(VAR)
IO  output(VAR)
CALL  UserDefinedName
Token-Class
identified by the Lexer

8. SVAR  UserDefinedName NVAR  UserDefinedName ASSIGN  SVAR = String
VAR  SVAR
VAR  NVAR
SVAR  UserDefinedName
NVAR  UserDefinedName
ASSIGN  SVAR = String
ASSIGN  SVAR = SVAR
ASSIGN  NVAR = NUMEXPR
NUMEXPR  NVAR
NUMEXPR  Number
NUMEXPR  CALC
Token-Class
identified by the Lexer
Token-Class
identified by the Lexer
Token-Class
identified by the Lexer

9. CALC  add(NUMEXPR,NUMEXPR)
CALC  sub(NUMEXPR,NUMEXPR)
CALC  mult(NUMEXPR,NUMEXPR)
COND_BRANCH  if(BOOL)
then{ CODE }
else{ CODE }

10. BOOL  eq(VAR,VAR) BOOL  (NVAR < NVAR) BOOL  (NVAR > NVAR)
Note: Later in Project 2,
our Type Checker shall
deal with the question
what to do if one of the
variables is a string and
the other one a number.
BOOL  eq(VAR,VAR)
BOOL  (NVAR < NVAR)
BOOL  (NVAR > NVAR)
BOOL  not BOOL
BOOL  and(BOOL,BOOL)
BOOL  or(BOOL,BOOL)
Remark: You may have noticed that we do not have
explicit Boolean variables (e.g.: BVAR) in SPL. Later,
in Project 3, our Code Generator will represent “true”
and “false” implicitly by means of goto jumps in the
control flow of the translated SPL programs. It is thus
not necessary to have explicit Boolean variables in SPL.

11. COND_LOOP  while(BOOL)
{CODE}
COND_LOOP  for(NVAR=0 ; NVAR<NVAR ; NVAR=add(NVAR,1))

12. Some Additional Remarks
The language SPL is Turing-complete: with it you can specify all computable algorithms in the domain of the Natural Numbers.
On the following slides
you will see, for illustration, one small example of a meaningful SPL program
and you will get your TO-DO TASKS for this Part b of Project 1.

13. Small Example: SPL Program
input(x) ;
num = x ;
res = “unknown”;
str = “even” ;
checknumber ;
if( eq(res,str) )
then { output(str) }
else { output(res) } ;
halt ;
proc checknumber { continued on the next slide }
Comment:
Procedure Calls
can have Side Effects
on the Values of Variables.
Later, in Project 2,
our Scope Analyser
will deal with the problem of
which Variables can be “seen”
from “where” in SPL programs,
(i.e.: “globally” or only “locally”).

14. CODE inside checknumber{ ... }
n is now a local variable
which can be “seen” only
here inside checknumber!
The other variables are “seen”
from “outside” of checknumber.
Project 2 will handle this scope.
n = num ;
if ( (n<0) )
then { n = mult(n, –1) } ;
while( (n>0) )
{ n = sub(n,2) } ;
if( eq(n,0) )
then { res = “even” }
else { res = “odd ” } ;

15. for this Part b of Project 1
YOUR TASKS
for this Part b
of Project 1

16. TO DO (Step-by-Step)
With pen and paper, scrutinize the grammar of SPL to see if it is already suitable for parsing:
IF this is not yet the case, then make the grammar suitable for parsing with help of the grammar transformation techniques shown in Chapter 2 of the book.
On the basis of Chapter 2 of the book, implement a Parser that consumes the token list from the input file (Project 1a) and attempts to create an output file that contains the corresponding concrete syntax tree:
See the following slides for further details...
On the basis of the distinction between concrete and abstract syntax (book Chapter 2), implement a Pruning software which cuts all superfluous concrete symbols out of the file with the concrete syntax tree,
such that only the smaller abstract syntax tree remains standing in the output file of the Parser.

17. Additional Remarks on the Parser
If the parser encounters a syntax error in the grammatical structure of the string of tokens, the parser must output an error message which indicates to the user where the error has happened and what kind of error it was.
and then abort the parsing process (without completing the Syntax Tree construction)
The Nodes in the Syntax Tree are composite Data which must carry unique Node ID numbers as well as an additional pointer to an information table
which the compiler will later need for type checking and for scope analysis (Project 2)

18. Node in the SPL Syntax Tree
TABLE
unique node ID
unique
node ID
Text of the Node
pointer to table
Further information
(Project 2)
child pointers
Text of the Node is
either a NONTERMINAL from the Grammar,
or a Terminal Token identified by the Lexer.

19. ALL IN ALL: Input .txt LINKED LIST DATA FILE SYNTAX TREE FILE
Project 1a
Project 1b
(Parser)
Project 1b
(Pruning
concrete
to abstract
syntax tree)

20.  And now... HAPPY PAIR-CODING! Note: Plagiarism is forbidden!
Code sharing with other pairs
of project students is also not
allowed