Syntax & Semantics, and Language Design Criteria Lab 1 solution - - PowerPoint PPT Presentation

syntax semantics and language design criteria lab 1
SMART_READER_LITE
LIVE PREVIEW

Syntax & Semantics, and Language Design Criteria Lab 1 solution - - PowerPoint PPT Presentation

CS152 Programming Language Paradigms Prof. Tom Austin, Fall 2015 Syntax & Semantics, and Language Design Criteria Lab 1 solution (in class) Formally defining a language When we define a language, we need to keep two concepts in mind:


slide-1
SLIDE 1

CS152 – Programming Language Paradigms

  • Prof. Tom Austin, Fall 2015

Syntax & Semantics, and Language Design Criteria

slide-2
SLIDE 2

Lab 1 solution

(in class)

slide-3
SLIDE 3

Formally defining a language

When we define a language, we need to keep two concepts in mind:

  • What is the structure (syntax) of a given

program in the language.

  • What is the meaning (semantics) of a given

program.

slide-4
SLIDE 4

Defining Syntax

There are 2 parts to the syntax of a language:

  • Lexemes/tokens – the "words" of the language
  • Grammar – the way that words can be ordered

We'll review how a compiler (or interpreter) handles these parts.

slide-5
SLIDE 5

How a compiler works

Lexer/ Tokenizer

source code tokens …

Tokens are the "words"

  • f the language.
slide-6
SLIDE 6

How a compiler works

Lexer/ Tokenizer

source code tokens if (x < 42) { y++; } else { y = 42; } "if" "(" "x" "<" "42" ")" "{" "y" "++" ";" "}" "else" "{" "y" "=" "42" ";" "}"

Tokens are the "words"

  • f the language.
slide-7
SLIDE 7

How a compiler works

Lexer/ Tokenizer

source code tokens if (x < 42) { y++; } else { y = 42; } "if" "(" "x" "<" "42" ")" "{" "y" "++" ";" "}" "else" "{" "y" "=" "42" ";" "}"

There are several types of tokens:

  • Identifiers
  • Numbers
  • Reserved words
  • Special characters
slide-8
SLIDE 8

How a compiler works

Lexer/ Tokenizer Parser

source code tokens

Abstract Syntax Tree (AST)

The parser's job is to combine the tokens together into an abstract syntax tree.

slide-9
SLIDE 9

Parsing Example

Parser

"if" "(" "x" "<" "42" ")" "{" "y" "++" ";" "}" "else" "{" "y" "=" "42" ";" "}" 42 if < X 42 = y + y 1 = y

Note that y++ has disappeared in the AST. The ++ operator is an example of syntactic sugar.

slide-10
SLIDE 10

Formally defining language syntax

Context-free grammars define the structure of a language. Backas-Naur Form (BNF) is a common notation.

slide-11
SLIDE 11

Context-free grammar for math expressions (in BNF notation)

<expr> -> <expr> + <term> | <expr> - <term> | <term> <term> -> <term> * <factor> | <term> / <factor> | <factor>

slide-12
SLIDE 12

How a compiler works

Lexer/ Tokenizer Parser

source code tokens

Abstract Syntax Tree (AST) Compiler

Machine code

Interpreter

Commands

slide-13
SLIDE 13

Compilers and interpreters must derive meaning from the ASTs in order to turn programs into actions.

Approaches for formally defining the meaning of a language include:

  • Operational semantics
  • Denotational semantics
  • Axiomatic semantics
slide-14
SLIDE 14

Judging a language

slide-15
SLIDE 15

Louden & Lambert's Design Criteria

  • 1. Efficiency
  • 2. Regularity
  • 3. Security
  • 4. Extensibility
slide-16
SLIDE 16

Efficiency

Can mean different things, such as

  • Machine efficiency

– Does the language give tips to the compiler for more efficient compilation?

  • Programmer efficiency

– How easy is it to write in the language? – How expressive is the language? (conciseness helps)

  • Reliability

– How difficult is code maintenance?

slide-17
SLIDE 17

Efficiency

Java: int i = 10; String s = "hi"; Python: i = 10 s = "hi"

  • Machine efficiency:

Java offers tips to the compiler

  • Programmer efficiency:

Python reduces the amount of typing required

slide-18
SLIDE 18

Regularity

Not always well-defined, but can be divided into

  • Generality: avoids special cases in favor of

more general constructs

  • Orthogonal design: different constructs can

be combined with no unexpected restrictions

  • Uniformity: similar things look similar,

different things look different

slide-19
SLIDE 19

Bad uniformity example (PHP): Same things look different

Inconsistent function naming:

  • isset()
  • is_null()
  • strip_tags()
  • stripslashes()
slide-20
SLIDE 20

Bad uniformity example (Pascal): Different things look the same

function f : boolean; begin ... f := true; end;

Return value is true

slide-21
SLIDE 21

Security

  • Stop programmer from making errors (or

handle them gracefully when they arise). Closely related to reliability.

  • Strong typing prevents some run-time errors.
  • Semantically-safe languages prevent

executing code that violates the definition of the language.

– Contrast array handling by Java and by C/C++

slide-22
SLIDE 22

Safety (Java vs. Scheme)

Java: int x = 4; boolean b = true; if (b) { x++; } else { x = x / "2"; } Scheme: (let ([x 4] [b #t]) (if b (+ 1 x) (/ x "2")))

slide-23
SLIDE 23

Extensibility

With an extensible allows the programmer to add new language constructs easily. Macros in Lisp and Scheme specify the syntax

  • f code that expands to other code.
slide-24
SLIDE 24

Lab 2: More Scheme practice

  • Download lab2.rkt from the course website

– Implement reverse function – Implement add-two-lists – Implement positive-nums-only

  • Using Louden & Lambert's criteria, compare

Java & Scheme (or two languages of your choice)