Lecture Notes on Compilation and Interpretation in CPSC 326 (Spring 2013), Study notes of Programming Languages

Download Lecture Notes on Compilation and Interpretation in CPSC 326 (Spring 2013) and more Study notes Programming Languages in PDF only on Docsity!

Today ...

• Quiz 9
• Language implementation (intro)
• Prolog negation as failure (if time)

Homework ...

• HW 10

Compilation and Interpretation

Compiler (think C/C++)

---

---

______^ Compiler^

Target Program

input (^) output

Source Code (^) (a program)

input

output

#include int main() { std::cout << “Hello World!\n”; return 0; }

pushq %rbp movq %rsp, %rbp movq %rdi, -8(%rbp) cmpq %rax, %rdx jae L

55 89 e5 53 83 ec 04 83 e4 f0 e8 31 00 00 00 89 c3 e8 2a 00 00 00 39 c 74 10 8d b6 00 00 00 00 39 c3 7e 13 29 c3 39 c Source Code Assembly Machine code

• translates source code into a target program
• target program often written in machine code

Compilation generally results in faster programs

• use various optimizations for target machine, memory management, etc.

Interpretation is often convenient

• debugging, learning a language, ad hoc scripting

Many interpreted languages can also be compiled

• including ghci and swi

Many compiled languages often use interpretation

• e.g., Java and C#
• debuggers as another example

Blurring the lines

Many language implementations include both

---

---

---

Translator

Interpreter (VM)

input output

Source Language

input

output

---

---

---

Intermediate Language

input

• Interpreted language implementations
  • simple translators ... all work is in the interpreter
  • straight-forward mapping to intermediate language
• Compiled language implementations
  • complex translators ... all work is in the translator
  • perform syntax and semantic analysis (e.g., optimization)
• Java is a hybrid
  • has both a translator (to bytecode)
  • and an interpreter (JIT compilation)
  • and both are complex

Lexical Analysis (“Scanning”)

Tokens are the smallest meaningful units of a program

Examples:

• Special words (the “reseverved” words)
  • int, if, while, new, class, public, this, etc.
• Operators
  • +, =, ==, <=, etc.
• Identifiers
  • variable names, function names, class names, etc.
• Constants (or the “literals”)
  • int, float, double, Boolean, string values

White space and comments are (usually) not tokens

In lexical analysis ...

• The goal is to simplify syntax analysis (parsing) ... and detect errors early

int main() { int x = 0; }

INT, ID(main), LPAREN, RPAREN, LBRACKET, INT, ID(x), OP(=), CONST(0), SEMICOLON, RBRACKET

• Input code is converted to a sequence (a stream) of tokens
• Removes non-tokens (white space, comments)
• Tokens stored with with their corresponding line and column numbers

In syntax analysis ...

INT, ID(main), LPAREN, RPAREN, LBRACKET, INT, ID(x), OP(=), CONST(0), SEMICOLON, RBRACKET

fun-def

decl-spec

type-spec

INT

decl

ID(main)

…

• token stream is analyzed to ensure it follows the language syntax
• the syntax is defined by the language’s grammar
• the grammer is used to create a derivation (parse tree)

In semantic analysis ...

• represent and analyze the “meaning” of the program
• representation via an Abstract Syntax Tree (AST)
  • distills syntax down to basic operations
  • built as the program is parsed
• usually includes a “symbol table”
  • symbol ids, names, and their types
• enforces “language rules” not represented by the grammar
  • identifiers declared before use
  • functions called with correct number of arguments
  • type checking

Scanning (Lexical analysis)

Basic idea

• takes the program code
• produces a stream of identified tokens
• removes whitespace, comments, etc.

Implemented using either

• a lexical analyzer tool (Lex, Flex, JFlex, ...)
• or as an ad hoc program (hand written)

Scanner usually called one token at a time

Scanner Parser

---

---

---

Source Code

read more input nextToken()

Ad hoc scanning (see textbook)

Define a set of token symbols

#define LPAREN 0 #define RPAREN 1 #define SEMICOLON 2 ...

Define a Token class

class token { private: int token_type; // the type of symbol int token_line; // line number int token_column; // column number string token_lexeme; // "lexeme" (nums, vars, etc) public: token(int type, int line, int col, int lexeme); int type() const; int line() const; int column() const; string lexeme() const; };

• lexer (scanner) converts program text to a stream of tokens
• each token is returned by scanner as a token object

Negation as Failure

Queries (goals) are always true or false in Prolog

?- member(a, [a, b]). true. ?- member(c, [a, b]). false.

• when true ...
  • prolog has proved (or solved) the query
  • the “proof” (solution) is given by the proof tree
• when false ...
  • prolog failed to prove the goal

Negation as failure

• In prolog, failure to prove the goal means:
  • the goal cannot be derived from the KB
  • and since it cannot be derived, it is assumed false
• Also known as the “closed world assumption”
  • the KB is assumed to have all the facts
  • if a fact is not in the KB, it is assumed to be false
  • similar to relational databases
  • differs from the “open world assumption” (just because it isn’t a fact, doesn’t mean it is false).

Prolog provides a not predicate

?- not(member(c, [a, b])). true.

• not is true if its argument is false
• in swi, we can also use the + operator

?- + member(c, [a, b]). true.

?= + member(a, [a, b]). false.

Consider this rule

sibling(X, Y) :- parent(P, X), parent(P, Y).

Q: can you see a problem?

• Lets say we have these facts:

parent(alice, bob). parent(alice, charlie).

• What does this query return?

?- sibling(bob, bob).

• Sibling should be anti-reflexive!