Lecture 4: The Declarative Sequential Kernel Language. September 5th 2011

Transcription

1 Lecture 4: The Declarative Sequential Kernel Language September 5th

2 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 2

3 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 3

4 Scanning contd Try it! The file code/mdc-scanner-manual.oz contains an implementation of the mdc scanner, and the file code/mdc-scanner-manual-wrapper.oz contains a functor wrapper needed for compilation. Compile the files: ozc -x mdc-scanner-manual-wrapper.oz -o mdc-scanner Execute the binary:./mdc-scanner -e "1+f*pep" What happens? 1 In practice, we would want the tokenizer to recover and proceed with the rest of the input. 4

5 Scanning contd Try it! The file code/mdc-scanner-manual.oz contains an implementation of the mdc scanner, and the file code/mdc-scanner-manual-wrapper.oz contains a functor wrapper needed for compilation. Compile the files: ozc -x mdc-scanner-manual-wrapper.oz -o mdc-scanner Execute the binary:./mdc-scanner -e "1+f*pep" What happens? There is no lexeme starting with the character e, and an error is reported. 1 The output is: [int(1) op( + ) cmd(f) op( * ) cmd(p) error] 1 In practice, we would want the tokenizer to recover and proceed with the rest of the input. 4

6 Scanning contd Example (A manual scanner for mdc code fragment) fun {Iterate State Seen Input Output} case Input of nil then if State == start then Output elseif State == int then int(seen) Output end [] Char Rest then if State == start then if Char == 32 then {Iterate start nil Rest Output} elseif {List.member Char "pf"} then {Iterate start nil Rest cmd(char) Output} elseif {List.member Char "+-*/"} then {Iterate start nil Rest op(char) Output} elseif {List.member Char " "} then {Iterate int Char Seen Rest Output} else error Output end elseif State == int then if {List.member Char " "} then {Iterate int Char Seen Rest Output} else {Iterate start nil Input int(seen) Output} end end end 5

7 Scanning contd Manual implementation of scanner DFAs is tedious and error-prone. We need to design a DFA corresponding to a set of regular expressions, then hard-code it using nested conditionals. There is a way out: we can use a scanner-builder tool. One of the most known scanner-builder tools is... 6

8 Scanning contd Manual implementation of scanner DFAs is tedious and error-prone. We need to design a DFA corresponding to a set of regular expressions, then hard-code it using nested conditionals. There is a way out: we can use a scanner-builder tool. One of the most known scanner-builder tools is lex. lex takes as input a lexical specification of a language in the form of a set of regular expressions and necessary bits of source code, and returns source code implementing a scanner DFA. Originally, lex produced C code, but versions for many other languages exist now (e.g., plex for Pascal, jflex for Java, flex++ for C++, etc.). yacc ( yet another compiler-compiler ) is an accompanying tool used to build compilers. Other scanner- and parser-builder tools include ANTLR, which can produce source code in C, C++, C#, Java, and Python; and Gump, the Oz tool for building scanners and parsers. 6

9 Scanning contd Try it! The file code/mdcscanner.ozg contains a specification of the mdc scanner, written as Oz/Gump code. The file code/mdc-scanner-gump.oz provides a simple wrapper that uses the scanner, and a few test cases. Open the files in the OPI (oz & and C-x C-f). Execute the code in mdc-scanner-gump.oz (C-. C-b). Consider the input 1+f*pep. What happens? 7

10 Scanning contd Try it! The file code/mdcscanner.ozg contains a specification of the mdc scanner, written as Oz/Gump code. The file code/mdc-scanner-gump.oz provides a simple wrapper that uses the scanner, and a few test cases. Open the files in the OPI (oz & and C-x C-f). Execute the code in mdc-scanner-gump.oz (C-. C-b). Consider the input 1+f*pep. What happens? The character e is not part of any valid lexeme, and an error is reported. The scanner recovers from the error and scans the rest of the input. The output is: [int(1) op( + ) cmd(f) op( * ) cmd(p) error(e) cmd(p)] 7

11 Scanning contd Example (A scanner specification for mdc code fragment) lex digit = <[0-9]> end lex command = <[pf]> end lex operator = <[\+\-\*\/]> end lex integer = <{digit}+> end lex <{command}> C in GumpScanner. class, getatom(?c) GumpScanner. class, puttoken( cmd C) end lex <{operator}> O in GumpScanner. class, getatom(?o) GumpScanner. class, puttoken( op O) end lex <{integer}> I in GumpScanner. class, getstring(?i) GumpScanner. class, puttoken( int {String.toInt I}) end Read more about the Oz scanner- and parser-builder in the Oz docs

12 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 9

13 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 10

14 The Declarative Model of Computation Models of Computation A model of computation is a programming language with formally defined syntax and semantics. (This definition is taken from the pensum book, and is not necessarily widely accepted.) The declarative sequential language defined in Ch. 2 of CTMCP is a subset of Oz. The declarative sequential kernel language is a subset of the declarative language. All models of computation presented further in CTMCP are extensions of the declarative model, and are realized as extensions of the declarative kernel language. 11

15 The Declarative Model of Computation contd What are the properties of the declarative model? The model is sequential all computations are performed in a linear order. The model is declarative all computations are independent of any external state and are themselves stateless and deterministic. The model supports both pure functional programming and pure deterministic logic programming. 12

16 The Declarative Model of Computation contd Practical declarative sequential language vs. declarative sequential kernel language. We first define the syntax and semantics of a simple kernel language. The kernel language contains constructs essential for the desired model of computation. Programs in the kernel language are typically very verbose. 3 We thus define a practical language by providing syntactic translations from its constructs to constructs in the kernel language. The practical language does not extend the model of computation, but makes programming more convenient just sue to the additional useful (though not essential) syntactic constructs. 3 Another example of the tradeoff between the implementer s and the user s convenience. 13

17 The Declarative Model of Computation contd Practical language vs. kernel language Practical language translation Kernel language semantics Benefits of the stratified approach: Specification of the semantics is easier for the kernel language than for the practical language. Additional constructs in the practical language are translated syntactically, and their semantics is thus already defined by the semantics of the kernel language constructs to which they translate. 14

18 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 15

19 Syntax of the Declarative Kernel Language Note: Most of the time you will be programming in the practical language, not in the kernel language. All syntactic constructions of the kernel language are valid in the practical language, but not vice versa. It is easier to write programs in the practical language using its additional features, but such programs are not valid in the kernel language. Programs in the practical language can be automatically translated into the kernel language by the compiler (compile with the option -E or --core); within the OPI (menu Oz Core syntax). 16

20 Syntax of the Declarative Kernel Language contd Kernel language syntax (CTMCP Tab. 2.1, p. 49) 4 statement ::= skip statement statement local id in statement end id = id id = value if id then statement else statement end case id of pattern then statement else statement end { id { id } } Be careful to distinguish between 5 { and } used as metalanguage symbols 6 and used as part of the language specified. 7 4 CTMCP makes an effort to discern between variable names (identifiers) and variables: the former are part of the syntax, the latter are part of the semantics. Thus we use id rather than variable. 5 One example of where the authors are not careful enough. 6 The EBNF symbols for denoting the number of occurences of a sequence. 7 The Oz symbols for procedure application. 17

21 Syntax of the Declarative Kernel Language contd Kernel language syntax (Tab. 2.2, p. 50) contd value ::= number record procedure number ::= integer float pattern ::= record record ::= literal literal ( { feature : id } ) procedure ::= proc { $ { id } } statement end literal ::= atom bool feature ::= atom bool integer bool ::= true false The variables (non-terminals) id, atom, integer, and float have microsyntactic (lexical) definitions. 8 The latter two are intuitive, the former two can very roughly be characterized as words that start with an upper- or lower-case letter, respectively. 8 See App. B and C in CTMCP. 18

22 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A statement can be a do nothing statement: statement ::= skip The rule is non-recursive. Example (Statements) skip The code above has one parse tree, with a unique, one-step derivation. 9 9 One step, two sentential forms. 19

23 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A statement can be a sequence of statements: statement ::= statement statement The rule is recursive, and leads to an exponential expansion of the sentential form. 10 Example (Statements) skip skip skip skip The code above has many parse trees, and all its derivations are based on just two rules. 10 The rule is in fact tree-recursive. 20

24 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A statement can be a variable declaration: statement ::= local id in statement end The rule is (linearly) recursive. Example (Statements contd) local X in local Y in skip end end The code above has one parse tree, and can be derived using three rules. 21

25 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A statement can be a variable-variable unification: statement ::= id = id The rule is non-recursive. Example (Statements contd) local X in local Y in X = Y end end The code above has one parse tree. 22

26 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A statement can be a variable-value unification: statement ::= id = value The rule is potentially recursive. 11 Example (Statements contd) local X in X = 1 end The code above has one parse tree. 11 Through the sequence value procedure statement. 23

27 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A statement can be a conditional: statement ::= if id then statement else statement end The rule is recursive. Example (Statements contd) if X then skip else if Y then local X in skip end else skip end end The code above has one parse tree. 24

28 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A value can be a record: record ::= literal literal ( { feature : id } ) The rule is non-recursive. Example (Record values) Literal = literal Empty = empty() Record = record(feature:field) Course = course(title:title subject:subject lecturer:lecturer) The code above has more than one parse tree. (Why?) 25

29 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A value can be a record: record ::= literal literal ( { feature : id } ) The rule is non-recursive. Example (Record values) Literal = literal Empty = empty() Record = record(feature:field) Course = course(title:title subject:subject lecturer:lecturer) The code above has more than one parse tree. (It is a sequence of statements; but each single statement in the sequence has one parse tree.) 25

30 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A statement can be a pattern matching statement: statement ::= case id of pattern then statement else statement end The rule is recursive. Example (Statements contd) case X of record(feature:x) then X = 1 else Y = r(f:x) end The code above has one parse tree It also makes perfect sense wrt. the semantics; more on this later. 26

31 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A value can be a procedure: procedure ::= proc { $ { id } } statement end The rule is potentially recursive. Example (Procedure values) Skip = proc {$} skip end Unify = proc {$ X Y} X = Y end Both Skip and Unify are applicable see next slide. 27

32 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A statement can be a procedure application: statement ::= { id { id } } Example (Statements) local X in local Y in X = proc {$ Z} X = Z end {X Y} {Y X} end end X is applied to Y, and Y is applied to X. 28

33 Syntax of the Declarative Kernel Language contd Kernel language syntax contd A value can be an identifier, a number, a record, or a procedure: value ::= number record procedure In addition, we will want to use arithmetic operators, etc., with the following syntax (table 2.3 page 55): value ::= id operator id... but the operations these denote are, in fact, already handled by procedure application. These are syntactic extensions and strictly speaking are not valid in the kernel language. But we will use them for the simplicity of notation. 29

34 Syntax of the Declarative Kernel Language contd Example (Arithmetic operations as values) This simple code: X = is equivalent to this convoluted kernel language code: 13 local Add in local A in local B in Add = Number. + A = 1 B = 2 {Add A B X} end end end 13 If you use automatic translation of code into the kernel language, the result will differ. The translator is not fully compliant with the book s specification. 30

35 Syntax of the Declarative Kernel Language contd Additional specifications Variables must be declared before they are used. Example (Variable declarations) The following is a valid program: local X in local Y in X = Y end end The following is not: local X in X = Y end 31

36 Syntax of the Declarative Kernel Language contd Additional specifications contd Features in a record must be unique no two fields in a record can have the same feature. Example (Record features) The following is a valid program: local X in local Y in local Z in X = label(feature1:y feature2:z) end end end The following is not: local X in local Y in local Z in X = label(feature:y feature:z) end end end 32

37 Syntax of the Declarative Kernel Language contd Browse and Show The procedures Browse and Show do not belong to the declarative sequential kernel language. They arenot declarative they perform side effects (I/O). Browse is not sequential it starts a separate thread each time it is called. We will use them extensively to be able to see what our programs do. Example (Browse) local X in X = proc {$ X} case X of variable(value:y) then {Browse Y} else {Browse X} end end end 33

38 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 34

39 Types What is a type? A type is a set of values together with a set of operations on these values. We can define, for example, the type integer as the set of all integer numbers together with the operations of addition, subtraction, multiplication, and division. In programming languages, types can be built-in (e.g., int, double, etc.); user-defined (e.g., using the keyword typedef in C or C++). 35

40 Types contd Built-in types in Oz (fig. 2.16, p. 51) Value Number Record Procedure... Int Float Tuple... Char Literal List... Bool Atom... String True False 36

41 Types contd Questions What about the truth values true and false in other languages? 37

42 Types contd Questions What about the truth values true and false in other languages? A language where there are no separate Boolean values? 37

43 Types contd Questions What about the truth values true and false in other languages? A language where there are no separate Boolean values? A language where 0 means false and 1 means true? 37

44 Types contd Questions What about the truth values true and false in other languages? A language where there are no separate Boolean values? A language where 0 means false and 1 means true? A language where 0 means true and 1 means false? 37

45 Types contd Questions What about the truth values true and false in other languages? A language where there are no separate Boolean values? A language where 0 means false and 1 means true? A language where 0 means true and 1 means false? A language where 0 means true and 1 means true? 37

46 Types contd What is type checking? Type checking is validation of programs aimed at detecting illegal application of operations (application of operations not supported for a specific type or types). There are two variants of type checking dynamic and static type checking: Static: Performed before a program is executed (i.e., at compile-time). Dynamic: Performed during the execution of a program, before the execution of each individual operation (run-time type-checking). Types and type checking are not particularly well covered in the book. This is a large topic and we will not go into details, and will return to these issues only occasionally during later lectures. 38

47 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 39

48 Kernel Language and Practical Language How to define a practical language? We can define a practical language on top of the kernel language by: adding syntactic sugar syntactic conveniences that allow for a more concise and readable syntax without introducing abtractions; adding linguistic abstractions syntactic conveniences that not only allow for more concise programs, but also introduce new programming structures, without extending the model of computation. In practice, distinguishing between syntactic sugar and linguistic abstractions may not be easy. 40

49 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 41

50 Syntactic Sugar Nested values Allow the syntax of records and patterns to include as arguments not only identifiers, but also values. Example (Nested values) Instead of X = 1 Y = y(x:x) Z = z(y:y) write 42

51 Syntactic Sugar Nested values Allow the syntax of records and patterns to include as arguments not only identifiers, but also values. Example (Nested values) Instead of X = 1 Y = y(x:x) Z = z(y:y) write Z = z(y:y(x:1)) 42

52 Syntactic Sugar contd Multiple variable declarations Allow the syntax of variable declaration to declare more than one variable at a time Example (Multiple variable declarations) Instead of local X in local Y in... end end write local X Y in... end 43

53 Syntactic Sugar contd Variable initialization Allow the syntax of variable declaration to initialize variables at the same time. Example (Variable initialization) Instead of local X in X = 1... end write local X = 1 in... end 44

54 Syntactic Sugar contd Nesting markers Allow the use of nesting markers to turn statements into expressions. Example (Nesting markers) Instead of local Z in {Procedure X Y Z} {Browse Z} end write local Z = {Procedure X Y $} in {Browse Z} end 45

55 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 46

56 Linguistic Abstractions Functions Add syntax that allows to define functions. The application of a procedure is a statement there is no return value. The application of a function is an expression there is a return value. Example (Functions) Instead of Procedure = proc {$ Argument Result} Result = 2*Argument end {Procedure 1 X} write Function = fun {$ Argument} 2*Argument end X = {Function 1} 47

57 Linguistic Abstractions contd In the practical language, procedures can in fact be used as if they were functions. Example (Procedures as functions) Double = proc {$ Input Output} Output = 2 * Input end local Four in {Double 2 Four}... end local Four = {Double 2 $} in... end local Four = {Double 2} in... end The last form (without the nesting marker) will work only if it is the last argument which is bound to the return value In the relational progamming model where we add non-deterministic choice and search spaces, we can treat, in principle, each procedure parameter as the return value. 48

58 Linguistic Abstractions contd Record field accession Add syntax that allows partial matching of record fields. Example (Record field accession) Instead of 15 case R of label(feature1:_ feature2:_ feature3:value3) then X = Value3 end write case R of label(feature3:value...) then X = Value end 15 The underscore ( ) denotes an unnamed variable, and is used to keep values we do not care about. 49

59 Linguistic Abstractions contd Record field accession Add syntax that allows direct access to records fields. Example (Record field accession) Instead of case R of record(feature:value...) then X = Value end write X = R.feature 50

60 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 51

61 Further Extensions What if we do not know the label of a record? Can we pattern-match it? Example (Record labels) The following does not work: case R of Label(...) then X = Label end We can use built-in procedures available from the module Record: X = {Record.label R} Note: The above is of course not in the kernel language, but it can be easily translated into a kernel language statement. 52

62 Further Extensions Example (Investigating the properties of a record) code/records.oz local X = x(id:x) Y = y(id:y x:x) proc {Investigate R} if {Record.is R} then {Browse record(label:{record.label R} features:{record.arity R})} end end in {Investigate X} {Investigate Y} end Note: Record.arity returns a list of features sorted alphanumerically. 53

63 Further Comments Keywords and reserved words A keyword is a lexeme that has some special meaning in the language, and may be related to some specific syntactic and semantic rules. Most languages have keywords. A reserved word is a lexeme that can be used only as a keyword. Some languages treat all keywords as reserved words, others do not. 54

64 Further Comments contd Example (Keywords and reserved words) code/real-integer.f95 program realinteger real integer! real variable named integer integer real! integer variable named real real = 0 integer = 0 write (*,*) "real: ", real write (*,*) "integer: ", integer end program realinteger Here, both real and integer are used both as keywords and as variable identifiers they are not reserved words. 55

65 Further Comments contd Example (Keywords and reserved words) code/keywords.f95 program integer! program named integer integer program, subroutine, if, end! integer variables type :: type! complex type named type integer integer! integer member named integer end type type (type) :: else, write! variables of the type named type program = 1 subroutine = 2 if = 3 end = 4 else%integer = 5! assign to the integer member of else write%integer = 6 write (*,*) program, subroutine, if, end, else, write end program integer In Fortran, program, integer, subroutine, if, end, type, and write are keywords, but not reserved words. 56

66 Further Comments contd Try it! Try out the above examples by compiling and executing them: 16 $ gfortran keywords.f95 -o keywords &&./keywords 16 You will need a Fortran compiler, e.g., gfortran, the GNU Fortran compiler. 57

67 Further Comments contd Example (Keywords and reserved words) code/keywords.scm ;; a simple procedure for displaying values (define (test value) (display value) (newline)) ;; some fancy definitions (define x 1) (define $?=... +) (define + 1) (define define 2) ;; and the testing (test x) (test ($?=... x 1)) (test ($?=... + x x)) (test ($?=... define define)) In Scheme, virtually no keyword is reserved, but details depend on the implementation. 58

68 Further Comments contd Try it! Try out the above examples by feeding them into a Scheme interpreter (or by compiling them first): 17 $ guile keywords.scm 17 Try, e.g., Guile, the GNU Scheme interpreter. 59

69 Further Comments contd In Oz, keywords are reserved words. But quoting a keyword creates an atom or variable identifier: 18 An atom is any lexeme matching the regular expression [a-z][a-za-z0-9_]*, except for reserved words such as local, true etc. But any lexeme matching [^ \\]+ is also an atom! Example (Quoted atoms) The following is perfectly legal (but try removing the quotes!): X = local X in end? ( if : then ) 18 Apostrophes ( ) for atoms, backticks/grave accents (`) for identifiers. 60

70 Further Comments contd In Oz, keywords are reserved words. But quoting a keyword creates an atom or variable identifier: 18 An atom is any lexeme matching the regular expression [a-z][a-za-z0-9_]*, except for reserved words such as local, true etc. But any lexeme matching [^ \\]+ is also an atom! Example (Quoted atoms) The following is perfectly legal (but try removing the quotes!): X = local X in end? ( if : then ) Note: x == x is true; true == true is false; local == local is invalid. 18 Apostrophes ( ) for atoms, backticks/grave accents (`) for identifiers. 60

71 Comments to Lecture 3 contd Identifiers in Oz using X_ is a valid identifier; _X is not an identifier: it is parsed as two separate tokens. 61

72 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 62

73 Declarative Programming We have introduced the declarative sequential kernel language (DSKL), which is expressive enough for some interesting applications. We have specified the syntax formally. We have introduced the meaning of the constructs by handwaving. We will discuss the semantics of DSKL, but first have a look at some practical examples. You will really need to have your Mozart environment up and running now. The declarative sequential language Declarativeness: An operation is declarative if, whenever called with the same arguments, it returns the same results independent of any other computation state. [CTMCP] Alternatively: A program is declarative if it specifies what should be achieved, not how it should be achieved. 63

74 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 64

75 Variables and Identifiers Variable declarations All variables have to be declared before they are used. In other words, any identifier has to be mapped to a variable before it appear in statements other than variable declarations. Example (Declaring a variable) Local scope: local X in... end Global scope: declare X in... More on declare, local, and lexical scoping later. 65

76 Variables and Identifiers contd Identifiers and variables How do identifiers and variables relate? An identifier is a syntactic entity, it is part of the program as a sequence of tokens. A variable is a semantic entity, it is part of the execution of a program. During an execution of a program, a variable declaration statement results in the creation of a new variable, the creation of a mapping from the identifier to the variable. The mapping is stored in an environment. More on this later. 66

77 Variables and Identifiers contd Example (Declared, unbound variable) We can declare a variable without binding it to a value: declare Identifier Identifier Environment Variable 67

78 Variables and Identifiers contd Example (Declared, bound variable) We can declare a variable and bind it to a value: declare Identifier in Identifier = value Environment Identifier Variable value binding The identifier is mapped to the variable. The variable is bound to a value. 68

79 Variables and Identifiers contd Example (Declared, bound variable alternative explanation) We can declare a variable and bind it to a value: declare Identifier in Identifier = value Identifier Environment value During the binding, the unbound variable is replaced with the value. The identifier is mapped onto the value. We don t care much, as this is an implementational detail. 69

80 Variables and Identifiers contd Lexical scope How long is an identifier-variable mapping valid? local declares a variable, introduces a new local environment, and maps the identifier to the variable in that environment. Outside of this local statement the environment is inaccessible, and the mapping is not valid. declare declares a variable, and maps the identifier to the variable in the global environment. The mapping is valid until the end of the program, or until another declaration using the same identifier. Declarations can also be implicit (e.g., in pattern matching or procedure bodies). More on lexical scoping, dynamic scoping, and macro expansion later. 70

81 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 71

82 Dataflow Variables Declarative (dataflow) variables In Oz, variables are declarative after the initial binding, they cannot be reassigned another value. CTMCP calls such variables dataflow variables. Variables are thus not particularly variable this may be counterintuitive, but it s not an Oz idiosyncrasy (e.g., Erlang employs the same design and terminology). Example (Declarative variables) declare X in X = hello X = dolly % (1) 72

83 Dataflow Variables Declarative (dataflow) variables In Oz, variables are declarative after the initial binding, they cannot be reassigned another value. CTMCP calls such variables dataflow variables. Variables are thus not particularly variable this may be counterintuitive, but it s not an Oz idiosyncrasy (e.g., Erlang employs the same design and terminology). Example (Declarative variables) declare X in X = hello X = dolly % (1) (1) This is an illegal attempt to reassign a new value to the variable which X is mapped to. 72

84 Dataflow Variables contd Example (Declarative variables contd) declare X in X = hello declare X in X = dolly % (1) 73

85 Dataflow Variables contd Example (Declarative variables contd) declare X in X = hello declare X in X = dolly % (1) (1) This is a legal first-time binding of the variable which X is mapped to; the second declare re-maps X to a new unbound variable, and the first variable becomes inaccessible. 73

86 Dataflow Variables contd Partial values Complex values (records) may contain unbound variables. Such values are called partial values. Example (Partial values) declare X Y in % (1) Y = label(feature:x) % (2) (1) Both X and Y are mapped to unbound variables. (2) Y is mapped to a variable bound to partial value a record containing the unbound variable which X is mapped to. 74

87 Dataflow Variables contd Example (Declarative variables contd) declare A B X X = x(a:1 b:b) % (1) X = x(a:a b:2) % (2) (1) We bind the variable which X is mapped to to a partial value. (2) We make an attempt to bind the variable which X is mapped to to another partial value. What happens to X? What happens to A and B? 75

88 Dataflow Variables contd Example (Declarative variables contd) declare A B X X = x(a:1 b:b) % (1) X = x(a:a b:2) % (2) (1) We bind the variable which X is mapped to to a partial value. (2) We make an attempt to bind the variable which X is mapped to to another partial value. What happens to X? What happens to A and B? Statements of the type id = value are actually not assignments, but unifications. In a unification, we (recursively) check whether two values are compatible, and perform nested bindings if necessary. Thus, A becomes bound to 1, and B to 2. 75

89 Dataflow Variables contd Note: Identifiers are mapped within environments onto variables. Variables are bound to values. In X = 1, the variable which X is mapped onto is bound to the value 1. 76

90 Dataflow Variables contd Note: Identifiers are mapped within environments onto variables. Variables are bound to values. In X = 1, the variable which X is mapped onto is bound to the value 1. For convenience, we will say that X is bound to 1. Strictly speaking, this is incorrect. 76

91 Dataflow Variables contd Unbound variables and freezing If an unbound variable is used in an operation that needs the value of the variable, the computation freezes. In the sequential model of computation it means that the whole execution of the program halts, as there is no way to provide the value. In a concurrent environment, it is just one thread that is kept waiting, while other threads may provide the needed value. 77

92 Dataflow Variables contd Example (Freezing) declare X Y in Y = X + 2 % (1) {Browse Y} (1) The computation freezes here neither X nor Y are bound. The interpreter waits for X to become bound because its value is needed to compute the arithmetic operation. There is no other thread which could do the binding, so we stop. 78

93 Lecture Outline Syntactic Analysis of Programs contd Scanning contd The Declarative Kernel Language Introduction Syntax of the Declarative Kernel Language Types and Type Checking The Practical Language Extensions Syntactic Sugar Linguistic Abstractions Further Extensions and Comments Declarative Programming Variables and Identifiers Dataflow Variables Summary 79

94 Summary This time Next time Syntax of the Declarative Sequential Kernel Language, extensions, handwaving semantics. Declarative variables, dataflow behaviour (freezing). Operational semantics of the Declarative Sequential Kernel Language the Kernel Language Virtual Mahchine. Declarative programming in Oz. 80

95 Summary contd Homework Pensum Questions...?...?...? Examine and try out today s code, read Mozart/Oz documentation if necessary. Read Ch. 2 in CTMCP (focus on the kernel language). All of today s slides, except for implementational details of the mdc scanners and examples in other languages than Oz. 81