MinML:
an idealized programming
language
CS 510
David Walker
MinML
• Reading:
– Pierce chapter 1, 9
• the meaning of program safety
• the typed lambda calculus
– Harper 5-8
• MinML
MinML
• MinML is an idealized programming
language based on the lambda calculus
• the definition of MinML includes
– a syntax for expressions involving recursive
functions, booleans and integers
– a dynamic semantics similar to the call-byvalue semantics of lambda calculus
– a set of typing rules to prevent programs from
incurring certain sorts of errors
syntax
• types:
t ::= int | bool | t1 -> t2
• expressions:
op ::= + | - | < | ...
e ::= x | n | b | e op e | if e then e else e
| fun f (x:t):t = e | e e
syntax
• A simple example:
fun fact (x : int ) : int =
if x <= 0 then 1
else x * fact (x-1)
dynamic semantics
• As we did for the lambda calculus, we will
define the dynamic semantics as a
relation:
e --> e’
• but we have some choices to make...
dynamic semantics
• there are at least two general approaches:
– by translation: describe execution by
translating the language into some lower-level
language
• we showed how to implement booleans, pairs in
the lambda calculus by translating them into
functions...
– language-based: describe execution entirely
in terms of language itself
• we showed how to implement functions in the
lambda calculus directly
translation-based approach
• Advantages
– clear implementation strategy in terms of lower-level
concepts
– sometimes simplifies complex language by translation
into a smaller core that can be more easily
understood
– if translation to machine-level
• facilitates low-level programming (writing device drivers;
interfacing with garbage collector)
• supports low-level “hacks” that depend upon specific
machines
translation-based approach
• disadvantages
– requires you understand how language is
compiled
• problematic if compilation is complex
– can prohibit portability and optimization
– run-time errors cannot necessarily be
understood in terms of the source program,
only in terms of how it is compiled and
executed
language-based models
• define execution entirely at the level of the
language itself
• advantages
– portable
– (for the most part) do not need to introduce
new concepts to explain execution
– simpler explanation of errors
language-based models
• disadvantages
– cannot take advantage of machine-specific
details
– does not to suggest a compilation strategy
– can be more difficult to understand the time
and space complexity
back to MinML dynamic semantics
• For MinML, we’re going to give the
dynamic semantics directly
• We will use a relation with the form
e1  e2
• values:
v ::= n | b | fix f (x:t1) : t2 = e
MinML dynamic semantics
• Primitive instructions:
n1 + n2  n
(when, mathematically,
the sum of n1 and n2 is n)
if true then e1 else e2  e1
if false then e1 else e2  e2
n = n  true
n = n’  false
(when n and n’ are
different numbers)
MinML dynamic semantics
• Primitive instructions:
v1 v2  e [v1/f] [v2/x]
(when v1 = fix f (x:t1) : t2 = e)
MinML dynamic semantics
• By the way, normally:
– I write the side conditions inside the body of
the rule
– express them using mathematical notation
rather than English
• examples:
(v1 = (fix f (x:t1) : t2 = e))
v1 v2  e [v1/f] [v2/x]
(n = n1 + n2)
n1 + n2  n
(n ≠ n’)
n = n’  false
MinML dynamic semantics
• Search rules
– recall, these rules specify the order of
evaluation
– we’ll use left-to-right, call-by-value:
e1  e1’
e1 op e2  e1’ op e2
e1  e1’
e1 e2  e1’ e2
e2  e2’
v1 op e2  v1 op e2’
e2  e2’
v1 e2  v1 e2’
e1  e1’
if e1 then e2 else e3  if e1’ then e2 else e3
MinML dynamic semantics
• once again, multi-step evaluation:
e * e
e  e’ e’ * e’’
e * e’’
some properties
• proposition 1 (values are irreducible)
– if v is a value then there is no e such that
v  e.
Proof?
some properties
• proposition 1 (values are irreducible)
– if v is a value then there is no e such that
v  e.
Proof? By inspection of the operational rules.
There is no rule with the form:
...... premises.......
ve
(To call this proof “inductive” is technically correct, but
misleading: we do not appeal to the inductive
hypothesis. We could also call it a proof “by case
analysis of the operational rules”)
some properties
• proposition 2 (determinacy)
– for every e there is at most one e’ such that
e  e’.
Proof?
some properties
• proposition 2 (determinacy)
– for every e there is at most one e’ such that
e  e’.
Proof? By induction on the structure of e.
case (fix f (x : t1) : t2 = e). This is a value. By
prop 1, there are no such e’.
case ...
some properties
• proposition 2 (determinacy)
– for every e there is at most one e’ such that
e  e’.
Proof? By induction on the structure of e.
case e1 e2:
subcase e1, e2 both not values: ...
subcase e1 value, e2 not value: ...
subcase e1, e2 both values: ...
some properties
• proposition 3 (determinacy of values)
– for every e there is at most one v such that
e * v.
Proof?
some properties
• proposition 3 (determinacy of values)
– for every e there is at most one v such that
e * v.
Proof? By induction on the multi-step relation + it helps
to be more formal about the induction hypothesis:
IH: If e * v and e * v’ then v = v’.
Proof uses prop 1 & 2.
stuck states
• not every irreducible expression is a value:
– if 7 then 1 else 2
– true + false
– 0 (17)
• an expression that is not a value, but for which
there exists no e’ such that e  e’ is stuck
• but, all stuck expressions are ill-typed
• if we type check programs in MinML before
running them, they will never get stuck
summary of
syntax & dynamic semantics
• MinML is an idealized language that
models some of the basic concepts in
functional programming
• the dynamic semantics satisfies some nice
properties: values are irreducible,
evaluation is deterministic
• Next up: typing MinML