Syntax notions: expressions, variables, symbols, forms

Semantic notions: types, values

The purpose of type management in programming languages is to prevent unfeasible computations, i.e., computations that cannot be completed due to improper applications of procedures to values. For example, prevent:

> (+ ((lambda (x) x) (lambda (x) x)) 4)

+: expects type <number> as 1st argument, given: #<procedure:x>; other

arguments were: 4

Language expressions (syntax) are assigned a type (semantics), so that well typing rules can be checked. For example, the above expression is not well typed, since that type of the + PRIMITIVE procedure is [number*Number –> Number], while the types of the given arguments

were [T –> T] and Number.

But, can we guarantee that expressions are well typed? CONSIDER:

> (define x 4)
> (+ 3
(if (> x 0)
(+ x 1)
"non-positive value"))
5
and
> (define x 0)
> (+ 3
(if (> x 0)
(+ x 1)
"non-positive value"))

+: expects type <number> as 2nd argument, given: "non-positive value";

other arguments were: 3

What happened? The expression (if (> x 0) (+ x 1) “non-positive value”) is not well typed. Depending on the runtime value of the variable x, it evaluates either to a number or to a string. Such expressions might CAUSE runetime errors when combined with other OPERATIONS.

Programming languages that enforce type checking at static time (before runtime), usually prohibit conditional expressions that might evaluate to different types. In Scheme (Dr. Racket), since types are checked at runetime, such conditionals are allowed, but should be handled with much care.

Syntax notions: expressions, variables, symbols, forms

Semantic notions: types, values

The purpose of type management in programming languages is to prevent unfeasible computations, i.e., computations that cannot be completed due to improper applications of procedures to values. For example, prevent:

> (+ ((lambda (x) x) (lambda (x) x)) 4)

+: expects type <number> as 1st argument, given: #<procedure:x>; other

arguments were: 4

Language expressions (syntax) are assigned a type (semantics), so that well typing rules can be checked. For example, the above expression is not well typed, since that type of the + primitive procedure is [number*Number –> Number], while the types of the given arguments

were [T –> T] and Number.

But, can we guarantee that expressions are well typed? Consider:

> (define x 4)
> (+ 3
(if (> x 0)
(+ x 1)
"non-positive value"))
5
and
> (define x 0)
> (+ 3
(if (> x 0)
(+ x 1)
"non-positive value"))

+: expects type <number> as 2nd argument, given: "non-positive value";

other arguments were: 3

What happened? The expression (if (> x 0) (+ x 1) “non-positive value”) is not well typed. Depending on the runtime value of the variable x, it evaluates either to a number or to a string. Such expressions might cause runetime errors when combined with other operations.

Programming languages that enforce type checking at static time (before runtime), usually prohibit conditional expressions that might evaluate to different types. In Scheme (Dr. Racket), since types are checked at runetime, such conditionals are allowed, but should be handled with much care.