EL - A simple expression language

1
EL - A simple expression language

• Syntax
• Transition semantics
• Deterministic transition semantics
• Natural semantics
• Treatment of errors

2
The Syntax

• A simple language
• arithmetic expressions with if
• Simplicity allows to concentrate on semantics

3

• The specs
• Domains
• bool, int (assumed given)
• op (operation names) (assumed given, the built-in
  ops)
• , , , lt, (and, or,
  excluded)
• Variable declarations
• b bool, n int, o op, e Expr
• Expr expressions of the language
• Syntax
• e b n o e e if e e e
  (e, , e)
• (boolean, integer, op name, application, if,
  tuple)

4
Terminology, Abstract syntax

• Application expression operator, operand
• each can be any expression
• If expression test, 1st branch, 2nd
  branch
• Tuple expression components
• Tuple as operand allows multi-arg
  operations
• Abstract Syntax trees have node labels
• Leaves bool, int, op (atomic exp.)
• Internal nodes applic, if, sequence (composite
  exp.)
• two expressions are equal iff their trees
  are identical

5
Conventions for concrete syntax

• (3, 4) may be written 34
• Parentheses used as needed
• Usual precedence laws
• Examples
• 3 (4 5) means (3, (4, 5))
• 3 4 5 means 3 (4 5)
• (how do their trees look like?)

6
Transition Semantics

• A configuration --- an expression
• An operation
• a rewriting of an expression by a
  reduction
• 345 ? 75
• if true 35 7 ? 35
• Can be deterministic (e.g, left-to-right)
• or non-deterministic (evaluate
  sub-expressions in any order)
• Initial version errors are ignored
• (extension to deal with error later)

7
Values

• A value a good/normal final configuration
• e.g. 7, true,
• value has to be specified as a first step in
  presenting a semantics
• It is an important semantic concept
• It is used in the specification of some
  semantics
• Errors are final configurations too

8
Specification of values (for EL)

• Domains
• Val values
• Variables
• v Val
• Values
• v b n o (v1, , vn)

9
Semantics of the built-in operations

• We assume it is given our interest is in the
  
• language constructs (application, if, )
• Assumption
• For each , a partial function
• from values to values is given.
• It is the meaning of o
• Additional assumptions as needed
• Q why partial?

10
Transition semantics rules

• (op-apply)
  (if defined)
• (eval-rator)
• (eval-rand)
• (eval-tuple)
• 
  (A rule schema, one instance for each n,i)
• ( Rules for if shortly)
• This is an inductive definition of a binary
  relation

11
An inductive definition ?
transitions supported by proof trees

Is there another proof tree for this
expression, -- for same transition? -- for
another?
Anything special about the tree form?
12

• Goal Resolution
• An expression E is given, find E s.t. E?E
• Given (35)(4 2), how do we find a transition?
• The rules provide guidance to
• finding new goals, sub-expressions of E
• Using solutions for the new goals to generate
  solutions for previous goals
• The procedure is recursive

13
Transitions for values a sanity check

• Q Is there a transition from 5?
• A No rules for int

Q What about transitions from values in general?
Can you prove the claim?
Q What is the role of values in goal resolution?
14
Rules for the if construct

• (if-apply-t)
• (if-apply-f)
• (eval-eval)
• Now, we have a complete set of rules denoted

15

• Examples (complete transitions, construct proof
  trees)
• Now, we have seen uses for all rules

16
Strictness
Q Can we define if as a built-in operation,
with the associated function defined by
A that would preclude many uses of if in
programming Examples ??
Same issue with AND OR these have to be defined
separately, not as the other built-in ops
17

• A composite expression E has a primary
  construct, with arguments Es direct
  sub-expressions
• Programming constructs application, if,
• During evaluation, these constructs are
  applied to their arguments, if certain
  conditions hold
• A programming construct is strict in an argument
  if the argument must be a value for the
  construct to be applied (non-strictness
  laziness)
• Application is strict in both arguments (relate
  to built-ins)
• If is strict only in its test (what about AND,
  OR?)

A step a transition
18

• Data structuring construct tuple
• It is not applied there is no associated
  step
• Requires all components to be evaluated

19
On the rules --- a discussion

• What are the roles of the axiom/ proper rules ?
• Why are the proper rules needed?
• can one do without them?
• The proper rules are propagation rules
• About the names of the rules

20
A deterministic semantics

• Q Which rules can we change, and how, to obtain
  a deterministic semantics ?

21
The rules (eval-rand-d) (ev
al-eval-d) Notation v in a rule an
implicit condition Is there a need to change any
of the other rules? Any relationship to
strictness for programming constructs?