Download Lecture 28: Software Building with Inductive Datatypes and Parser and more Assignments Computer Science in PDF only on Docsity!
Lecture 28: Finals Review Lecture
Lectured by Prof. Caldwell and scribed by Sunil Kothari
December 4, 2008
1 Review Lecture
Are there any questions about the HW?
What we have is an over arching idea, that you can use the inductively defined datatypes to describe abstract syntax for various little languages. Then you can write an evaluator for these languages. Finally we got to the parser for the little languages.
A parser maps strings into abstract syntax - which is some sort of a tree. strings parser ⇒ Inductively defined datatype/abstract syntax
evaluate analyse ⇒ output value.
This is a standard design for building software. You can use any language for this - functional as well as imperative.
We did an instance of this framework.
- Calculator - HW 15
(a) evaluator
- Lambda calculus - HW 16
(a) evaluator
- Type Inference - HW 20
(a) parse a lambda term and then do type inference analysis outputting the type if the term has one.
The thing is defining the intermediate languages is simple - just write down a data type.
Here’s a strong possible exam question. You may have to build something in this framework. For example, build an evaluator for a small logic language.
F ormula ::= V String | F T rue | F F F alse | And F ormula F ormula | Or F ormula F ormula | Implies F ormula F ormula
The equivalent grammar is:
F ormula ::= identif ier | ”(”F ormula ”&” F ormula ”)” | ”(”F ormula ”” F ormula ”)” | ”(”F ormula ” => ” F ormula ”)” | ”T ” | ”F ”
Q: Are we going to cover only the portion after midterm? A:Yes, but you are expected to know the material from the first half. If you get a programming job, you will get to do this framework over and over again. It’s pretty standard and its nicely done in functional world. 15 years ago, they were confined to purely academic setting.
We spent the last few weeks on type inference- and something like the same is happening in the Haskell.
We will start going through the HWs.
HW 13 was to give structural induction principle for STree.
data (Ord a) => Stree a = Null | Fork (Stree a) (Stree a)
The induction principle would be (P (N ull)∧∀t1 : Stree a.∀x : a.∀t2 : Stree a.(P (t1)∧P (t2)) => P (F ork t 1 x t2)) ⇒ ∀t : Stree a.P (t)
That HW was write map and fold on Stree.
Then we had a lecture on Rose Trees. There might be a question on Rose trees.
data Rose a = Node a [Rose a]
One interesting thing is that there is no empty tree.
Some examples:
where m′z = if z == ”x” then (N 5) elsem z.
Essentially, we are updating the function m to return N 5 when it sees x. Here m : string → Int.
Basically, the HW was to extend it with boolean values.
Lecture 19 was going over – you probably wanna read this - how this overloading works in the let case.
In Lecture 19 (goes with HW16), we generalize this idea over to capture avoid- ing substitution. In the HW, you were supposed to add a spread term.
The abstract syntax for the lambda terms is:
data Term = V String | Ap Term Term | Abs String Term | Pair term term | Spread Term (String,String) Term
The HW was to extend an evaluator to include spread-terms.
Lecture 21 ,lecture 22 and HW 17 were about unification. Remember that we were unifying types.
data Type = TyVar String | Arrow Type Type
Given two types t1 and t2, they are unifiable iff there exists a substitution σ such that σ t1 = σ t2. Remember σ is a substitution, mapping strings to types.
In the HW, you were to extend the unification algorithm to products.
In the HW 18 and Lecture 23 there was type inference. You were given the type inference algorithm and you were to extend to handle spread + pair terms and product types.
We have some context Γ, and we are trying to build the set of constraints. Once we get all the constraints, we use unification to get a substitution and apply that substitution to the type that we started with to get the actual type.
Rule for spread Γ, E 1 M : α × β {x : α, y : β} ∪ Γ, E 2 N : τ Γ, E 1 ∪ E 2 ` spread(M ; x, y.N ) : τ
The type inference algorithm was by induction on the structure of the term. Remember E1 and E2 are propagated down to the conclusion from each one of the hypotheses.
HW 19 was to do build the derivation and then generate constraint sets and there will be a couple of these in the final. The axiom rule:
Γ, {α = τ } ` x : α where x : τ ∈ Γ (Var)
The abs rule: Γ\x ∪ {x : α} M : β Γ , E ∪ {τ = α → β} λx.M : τ where α and β are fresh (Abs)
Example derivation of λx.x
(Var) [x : α], β = α x : β (Abs) [], {β = α, τ = α → α} λx.x : τ
The resultant constraint set is {α = β, τ = α → β} and the substitution is {α := β, τ := β → β} You won’t be asked to do the unification but certainly some derivations.
Lec 25, Lec 26 were on Monads and parsers.
Monads were defined as:
class Monad m where return :: a -> m a
(>>=) :: m a -> ( a -> m b) -> m b
(>>=) is a sequencing operator for monads and parsers were an instance of Monads.
When you show something is an instance of monad we get the do notation. The do notation for lists is like a looping structure which goes through each element of the list. Parsers were defined as:
newtype Parser a = MkP (String -> [(a,String)])
Applying a parser to a string is defined as:
apply:: Parser a -> string -> [(a,String)] apply (MkP f) s = f s
Monad instances of parser is defined as:
