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.

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 ...

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.

The Grammar of SPL

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.

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 !

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

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

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

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.

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

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.

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”).

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 ” } ;

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

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.

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)

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.

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)

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