Major elements of programming languages:
Syntax, Semantics, Pragmatics

Syntax: Readable, writable, easy to translate, unambiguous, ...

Formal Grammars: Backus & Naur, Chomsky

• First used in ALGOL 60 Report - formal description

• Generative description of language.

• Language is set of strings. (E.g. all legal ALGOL 60 programs)

<expression>  ::= <term> | <expression> <addop> <term>
<term>        ::= <factor> | <term> <multop><factor>
<factor>      ::= <identifier> | <literal> | (<expression>)
<identifier>  ::= a | b | c | d
<literal>     ::= <digit> | <digit> <literal>
<digit>       ::= 0 | 1 | 2 | ... | 9
<addop>       ::= + | - | or
<multop>      ::= * | / | div | mod | and

Grammar gives precedence and which direction op's associate

Extended BNF handy:

• item enclosed in square brackets is optional

  <conditional> ::= if <expression> then <statement> [else <statement>]
  

• item enclosed in curly brackets means zero or more occurrences

  <literal>::= <digit> { <digit> }
  

Problems with Ambiguity

	<statement> ::= <unconditional> | <conditional>

	<unconditional> ::= <assignment> | <for loop> | 

                              begin {<statement>} end

	<conditional> ::= if <expression> then <statement> |

                              if <expression> then <statement> else <statement>

Could be

1. if exp1 then (if exp2 then stat1 else stat2) or

2. if exp1 then (if exp2 then stat1) else stat2

Ambiguous

Pascal rule: else attached to nearest then

To get second form, write:

	if exp1 then 
		begin 
			if exp2 then stat1 
		end 
	else 
		stat2

MODULA-2 and ALGOL 68 require "end" to terminate conditional:

1. if exp1 then if exp2 then stat1 else stat2 end end

2. if exp1 then if exp2 then stat1 end else stat2 end

Why isn't it a problem in ML?

Ambiguity in general is undecidable

Chomsky developed mathematical theory of programming languages:

• type 0: recursively enumerable

• type 1: context-sensitive

• type 2: context-free

• type 3: regular

Not all aspects of programming language syntax are context-free.

• Examples include declaration before use and Go to statement.

1. programmer to generate syntactically correct programs

2. parser to recognize syntactically correct programs

Abstraction

Dijkstra: Originally we were obligated to write programs so that a computer could execute them. Now we write the programs and the computer has the obligation to understand and execute them.

Progress in programming language design marked by increasing support for abstraction.

Computer at lowest level is set of charged particles racing through wires w/ memory locations set to one and off - very hard to deal with.

In computer organization look at higher level of abstraction: interpret sequences of on/off as data (reals, integers, char's, etc) and as instructions.

Computer looks at current instruction and contents of memory, then does something to another chunk of memory (incl. registers, accumulators, program counter, etc.)

When write Pascal (or other language) program - work with different virtual machine.

• Integers, reals, arrays, records, etc. w/ associated operations

Pure translators

Compiler:

Preprocessor:

Execution of program w/ compiler:

Interpreter:

We will speak of virtual machine defined by a language implementation.

Machine language of virtual machine is set of instructions supported by translator for language.

Layers of virtual machines on Mac: Bare 680x0 chip, OpSys virtual machine, MacPascal (or Lightspeed Pascal) machine, application program's virtual machine.

We will describe language in terms of virtual machine

Slight problem:

• Different implementors may have different conceptions of virtual machine

• Different computers may provide different facilities and operations

• Implementors may make different choices as to how to simulate elts of virtual computer

Problem : How can you ensure different implementations result in same semantics?

Sometimes virtual machines made explicit:

• Pascal P-code and P-machine,
• Modula-2 M-machine and M-code,
• Java virtual machine.

Compilers and Interpreters

Two extreme solutions:

Pure interpreter: Simulate virtual machine (our approach to run-time semantics)

	REPEAT
		Get next statement
		Determine action(s) to be executed
		Call routine to perform action
	UNTIL done

Pure Compiler:

1. Translate all units of program into object code (say, in machine language)

2. Link into single relocatable machine code

3. Load into memory

Comparison of Compilation vs Interpretation

Rarely have pure compiler or interpreter.

• Typically compile source into more easy to interpret form.

• Ex. Remove white space & comments, build symbol table, or parse each line and store in more compact form (e.g. tree)

In FORTRAN, Format statements (I/O) are always interpreted.

Overview of structure of a compiler

Analysis:

Break into lexical items, build parse tree, generate simple intermediate code (type checking)

Synthesis:

Optimization (look at instructions in context), code generation, linking and loading.

Lexical analysis:

Break source program into lexical items, e.g. identifiers, operation symbols, key words, punctuation, comments, etc. Enter id's into symbol table. Convert lexical items into internal form - often pair of kind of item and actual item (for id, symbol table reference)

Syntactical analysis:

Use formal grammar to parse program and build tree (either explicitly or implicitly through stack)

Semantic analysis:

Update symbol table (e.g., by adding type info). Insert implicit info (e.g., resolve overloaded ops's - like "+"), error detection - type-checking, jumps into loops, etc. Traverse tree generating intermediate code

Optimization:

Catch adjacent store-reload pairs, eval common sub-expressions, move static code out of loops, allocate registers, optimize array accesses, etc.
Example:

		for i := .. do ...
			for j:= 1 to n do
				A[i,j] := ....

Code generation:

Generate real assembly or machine code (now sometimes generate C code)

Linking & loading:

Get object code for all pieces of program (incl separately compiled modules, libraries, etc.). Resolve all external references - get locations relative to beginning location of program. Load program into memory at some start location - do all addressing relative to base address.

Like to have easily portable compilers front-end vs back-end

Front-end generate intermediate code and do some peep-hole optimization

Back-end generate real code and do more optimization.

Semantics

• Operational semantics for most of course.

• How would an interpreter for the language work on virtual machine?

• Represent Code and Data portions of memory

• Has instruction pointer, ip , incremented by one after each command if not explicitly modified by the instruction.

Official language definitions: Standardize syntax and semantics - promote portability.

• All compilers should accept the same programs (i.e. compile w/o errors)

• All legal programs should give the same answers (modulo round-off errors, etc)

• Designed for compiler writers and as programmer reference.

Common Lisp, Scheme, ML now standardized, Fortran '9x.

Good formal description of syntax, semantics still hard.

Backus, in Algol 60 Report promised formal semantics.

• Said forthcoming in few months - still waiting.
• Years after introduction still problems and ambiguities remaining.