CSC 7101 Programming Language Structures Spring 2008

1. Louisiana State University CSC 7101Programming Language StructuresSpring 2008 Allyson M. Hoss, January 28, 2008

2. CSC 7101 Programming Language Structures • Research Assignment • Miscellaneous Issues • PL Design Goals • Syntax & Semantics • Attribute Grammars

3. Topic & References • Sources - published papers (incl. IEEE / ACM) • (not: class websites; blogs; advertisements) • Limit sources from Wikipedia • Trouble finding or accessing papers? • Do your own research! • Your research is YOURS! • Example Topic Description

4. Example of a Good Topic Description Topic: Parallel Programming Languages Focus: Usability on today's multi-core and future multi-core / multi-processor systems Approach: Compare & contrast programming languages, strengths and weaknesses w.r.t. multi-core processors Focus: Determine if current Software Development Toolkits built on top of existing languages are better suited and easier to use Systems: IBM's X10 language, Cray Inc's Chapel, possibly Sun's Fortress language.  Toolkits: OpenMP and Intel's Threading Blocks

5. Guidelines for Outline • Topic sentence(s) • Focus (narrowing the topic) • Approach (your review will take) • Address PL design goals of your topic • Include a comparative analysis table/diagram of related research organized based on your approach • Address open issues / research directions • Review syntax briefly … focus on semantics • Minimal review of HW

6. CSC 7101 Programming Language Structures • Research Assignment • Miscellaneous Issues • PL Design Goals • Syntax & Semantics • Attribute Grammars

7. Teaching Assistant • John W. Burris • Office Hours • Monday 11:00 AM - 12:30 PM • Tuesday 11:00 AM - 1:00 PM • Thursday by appointment • (with at least 12 hours notice) • Coates 162

8. Website My main home page will be: http://www.csc.lsu.edu/~hoss/index.html

9. Additional Reading Material Slonneger, K. and Kurtz, B., Formal Syntax and Semantics of Programming Languages:A Laboratory-Based Approach Addison-Wesley, Reading, MA, ISBN: 0-201-65697-3, 1995. http://www.cs.uiowa.edu/~slonnegr/plf/Book/ Please Read: Chapter 1, pp. 1-8; 21-29 Chapter 3, pp. 59-71

10. CSC 7101 Programming Language Structures • Research Assignment • Miscellaneous Issues • PL Design Goals • Syntax & Semantics • Attribute Grammars

11. Design Questions • What design decisions make each language different from the others? • Are these differences a result of minor syntactic rules or important underlying semantic issues? • Is a controversial design decision necessary to make the language appropriate for its intended use or was the design decision an accident?

12. Design Questions • Could different design decisions result in a language with morestrengths and fewer weaknesses? • Are the good parts of different languages mutually exclusive or could they be efficiently combined? • Can a language be extended to compensate for its weaknesses?

13. Design Goals What do you think are some design goals?

14. Design Goals • Initially: time (execution) vs space (memory) • Next: simplicity, expressiveness, generality • Then: reliability, maintainability, efficiency

15. Design Goals What do you think are the current goals today?

16. Design Goals NOW • Simplicity : easy to learn, use, understand • Robustness: security, safety • (strongly typed; restricts ptrs) • Portability: architectures • (run-time bytecode interpreters) • Internet Compatibility: access SW anywhere • (class libraries) • Concurrency: multi-interaction • (multi-threading & conc.primitives)

17. Programming Language Paradigms • Procedural or Imperative Functional Declarative Object-oriented Rule-based, Event-driven, Parallel or Concurrent, Scripting, Markup, Specification, Assembly, Visual, …

18. Procedural or Imperative Paradigm • Computation based on command such as • do this, do that, do the next thing • Variables represent memory locations • Assignment statements store values • Destructive assignment • Uses iteration for repetition • Acts on stored data, modifies system state • Assembly, Fortran, COBOL, C, C++, Java

19. Functional Paradigm • View programs as function definitions and sets of expressions • Computation based on math functions -“back boxes” accepts inputs and returns outputs • Apply functions to arguments • Minimal use of variable or assignment statements • No extraneous side effects • Natural recursion (primary form of repetition) • Lisp, Scheme, ML

20. Declarative (Logic) Paradigm • Not procedural : commands describe what is • and not how to • Computation using symbolic logic, facts, and rules • Typically interpreted • Looping via recursion • Prolog

21. Object-Oriented Paradigm • Data abstraction : object & methods • Information hiding • Classes, class hierarchy, instances of classes • Computation via interaction of objects • Inheritance • Smalltalk • OO features incorporated into most modern PL…C++, C#, Java

22. Defining a PL • Language: set of strings (infinite?) symbols from a finite alphabet • Language Specification: • Syntax: • arrangement of symbols • well-formedness (not ambiguous; values defined well • grammar • Semantics: meaning of syntactically valid strings • relationship between input and output • steps of program execution • rules for legal programs – often syntax can not describe • Pragmatics – extra information • Usage of the language (ease of use, efficiency) • Features of the implementation (optimization)

23. CSC 7101 Programming Language Structures • Research Assignment • Website • Additional Reading Material • Design Goals • Syntax & Semantics • Attribute Grammars

24. Syntax & Semantics • Syntax • how does a program “look” • form and structure of language constructs • (programs, procedures, statements, …) • Semantics • what do the language constructs “do” • meaning (behavior) of the syntactic units • (what does an “if” statement “do”)

25. Syntax & Semantics • Syntax • grammar of a natural language statement • a set of rules to define a language • Semantics • meaning of a natural language statement

26. English Grammar <sentence> ::= <noun phrase> <verb phrase> A sentence is a noun phrase followed by a verb phrase ::= can be read “is defined to be” or “is composed of” also written 

27. English Grammar <sentence> ::= <noun phrase> <verb phrase> <noun phrase> ::= <determiner> <noun> | <determiner> <noun> <prepositional phrase> <verb phrase> ::= <verb> | <verb> <noun phrase> | <verb> <noun phrase> <prepositional phrase> <prepositional phrase> ::= <preposition> <noun phrase> <noun> ::= boy | dog | leash | ball <determiner> ::= a | the <verb> ::= walked | threw <preposition> ::= with | to ::= can be read “is defined to be” or “may be composed of” also written 

28. Parse Tree

29. Parse Tree alone can not validate semantics

30. FORMALFORMAL SYNTAXSEMANTICS StaticDynamic BNFattribute grammars operational (Backus axiomatic Naur denotational Form)

31. Formal Syntax • Formal Translation Models • Grammar – a formal definition of syntax • Types of Grammars (0..3) • BNF

32. Formal Languages • Language: set of strings containing symbols from alphabet • What strings can you form over the alphabet {a, b} • {abbb} • {baa, baaa, baaaa, baaaaa, . . . } • {ab, aabb, aaabbb, aaaabbbb, aaaaabbbbb, . . . } • {aba, abba, abbba, …} • Definition of a formal language • model generates & recognizes all (and only) strings of a formal language

33. Formal Languages A programming language grammar is used to parse a program producing a parse tree. It contains every symbol in the input program as well as all sets of symbols used in the program's derivation Important role in the design and implementation of programming languages

34. Grammar • Required to define a formal language • Alphabet: finite set Σ of symbols • String: finite sequence of symbols • Empty string  • Σ* - set of all strings over Σ(incl. ) • Σ+ - set of all non-empty strings over Σ • Language: set of strings L  Σ* • Set of Rules to determine legal strings

35. Grammars • G = (T, N, S, P) • Finite set of terminal symbolsT • Finite set of non-terminal symbolsN • Starting non-terminal symbol S N • Finite set of productionsP • x y (x ::= y) • x  (N T)+, y  (N T)* • Applying a production: uxv  uyw

36. Grammars G = (T, N, S, P) terminalsymbols : symbols (words) of an alphabet (word set) from which strings of the language can be created; {a, b, c...} nonterminalsymbols : symbols describing sets of strings (syntactic categories) ; {A, B, C...} start symbol S: marks starting point for string derivations; unique in the grammar; productions : rules describing how each nonterminal is defined in terms of terminal symbols and nonterminals; ordered pairs of strings (x, y) such that x  y (x ::= y)

37. Grammar • String derivation – sequence of rule application • w1 w2 …  wn; denoted w1 wn • Language generated by a grammar • L(G) = { w  T* | S  w } • Traditional classification • Regular • Context-free • Context-sensitive • Unrestricted

38. Chomsky Hierarchy

39. Regular Languages (Type 3) • Most restricted • LHS is a single non-terminal • RHS has exactly one terminal and at most one nonterminal • All productions are A wB and A w • A,B  N and w  T* • Or all productions are A Bw and A w

40. Regular Languages Examples (Type 3) • L = { anb | n > 0 } is a regular language • S  Ab and A  a | Aa • What are the strings that can be generated using this language? • {ab, aab, aaab, …}

41. Regular Languages Examples (Type 3) • Binary numerals • B  0 • B  1 • B  0 B • B  1 B

42. Uses of Regular Grammar • Lexical analysis in compilers • e.g. identifier = letter (letter|digit)* • Token sequence for syntactic analysis done by parser • tokens = terminals for CFG • Pattern matching • grep “a\+b” foo.txt • Every line from program that contains a string from the language L = { anb | n > 0 } • i.e. the language for reg. expr. a+b

43. Context-Free Languages (Type 2) • LHS must be a single nonterminal ; • All productions are xAy --> xzy • or xAy --> xZy • A, Z N and z  T* and x,y = • A can be rewritten by the strings z or Z on the right regardlessof the context in which A finds itself • A  z, A  Z, Z  z

44. Context-Free Languages (Type 2) Example: L1 = { anbn | n > 0 } is c.f. but not regular L2 = {axby; x>0, y>0} What are the strings that can be generated using L1 and L2 languages? L1 {ab, aabb, aaabbb, …} L2 {ab, aab, aaab, …, abb, abbb, abbb, … aabb, aabbb, …}

45. Context-Free Languages (Type 2) S → AB S → ASB A → a B → b S AB aBab S  ASB  aSB  aABB  aaBB  aabB  aabb This grammar can be simplified by removing the nonterminals A and B, leaving just two rewrite rules: S  ab S  aSb

46. Uses of Context-Free Languages • Describe the essential features of all current PLs • Syntax of a programming language • e.g. Java • Terminals: identifiers, keywords, literals, separators, operators • Starting non-terminal: CompilationUnit • Implementation of most parsers in a compiler to determine syntactic structure and produce CFG parse trees • Backus-Naur Form (BNF) : alternative notation for context-free grammars; John Backus and Peter Naur, for ALGOL60

47. Limitations of Context-Free Languages • Cannot represent semantics • e.g. “every variable used in a statement should be declared in advance” • e.g. “the use of a variable should conform to its type” (type checking) • cannot say “string s1 divided by string s2” • Solution: attribute grammars • For certain kinds of semantic analysis

48. Context-Sensitive Languages (Type 1) • RHS contains no fewer symbols than LHS • All productions are xAy --> xzy • A  N and x,y,z  T* and z · ≠ Ø • A can be rewritten by zonly when it is in the context of x and y • (when the string x precedes N and the string y follows it) • Example Rule • ABC  AbbC

49. Context-Sensitive Languages (Type 1) • Example language • L = { anbncn | n >= 1} • More powerful than context-free grammars • All context-free languages are also context-sensitive • Not all context-sensitive languages are context-free

50. Recursively Enumerable Languages (Type 0) • No restrictions – most general grammar (linguists find useless) • aYb  bY Y  N and a,b  T* • Language accepted by a Turning machine • a general model of computation • (a finite-state machine in which each transition prints a symbol on a tape. – The tape head can move in either direction. – The tape is infinite to the right) • models a human being solving a problem in an algorithmic way