Menu

SI413 Class 18: Static vs. Dynamic Typing


Reading
Programming Language Pragmatics, Chapter 7 up through 7.1.1, plus the box at the bottom of p.292.

Homework
Study for Exam!

Review Homework
We spent a lot of time reviewing the HW in painful detail!

Problems with no type checking
Right now, our simple SPL interpreter does no type checking at all. This has implications from the merely annoying:
write 4 < 5;
1         # Why don't I get "true" as a result?
new sqr := lambda x { res := x*x; };
write sqr; 
134849776 # Why don't I get "function" as a result?
write sqr = 11612^2 + 11232;
1         # Functions and numbers shouldn't be equal!
... to the truly catastophic:
new sqr := 9;
write sqr(3);
Segmentation fault # The interpreter crashes and never knows why!
We like the idea that systems know how to print or read or otherwise manipulate objects based on their type, rather than having the programmer specify everything. Moreover, we like interpreters to recognize illegal operations and do the print-error-and-return-to-interpreter thing rather than crash. In our compiled code, we like errors like type mismatches to be found so that we don't have mysterious crashes once the code gets run. So type checking is important stuff.

Static vs. Dynamic
There are two basic ways to do type checking: static or dynamic. You should recognize those words by now!

Dynamic Typing
every object gets tagged with a type
each op has to check types of operands
P1: class Obj { int otype; int oival; bool obval; Node *ofval; };
P2: class Obj { int otype; union { int oival; bool obval; Node *ofval; }; };
New symbol table?
Show how it works.
Only finds errors when code is run!
Makes sense for interpreted languages.

Static Typing
Every name must have a type declaration.
We must do type inference!
Rules for SPL?


Christopher W Brown
Last modified: Thu Nov 5 09:05:49 EST 2009