dynamic vs. static typing

[Shriram Krishnamurthi <address@hidden>]

Steve Dekorte wrote:

>						 As I understand types, 
> in the context of pure OOP languages, the idea is to prevent "this 
> object does not respond to this message" errors. 

This is only for types whose purpose is to prevent "this object does
not respond to this message" errors.  There are type systems to deal
with all sorts of other properties, such as uniqueness, race-condition
avoidance, etc, etc.

>						   This is done by static 
> typing - putting labels on all the variables, arguments and return 
> values that indicate the list of methods to which the object referenced 
> or returned can respond to and doing a compile time check to ensure 
> that:
> 1. variables aren't sent messages which are not declared by their types
> 2. variables or arguments are not assigned to types which contain 
> methods which their declared types do not contain

Your informal definition of static typing is flawed in that it assumes
all variables have type labels (by which, presumably, you mean that
the programmer put them there).  This is true in many but not all
cases.  Therefore, I would not start out with that assumption.
(Likewise, there is no reason to believe the arguments and returns
have type labels annotated by the human, either.)

The rest of your definition (the enumerated list) is true for

- type systems that prevent "message not found" errors AND
- type systems that begin with the assumption of type annotations

I explained above why the first assumption is not universal.  As for
the second, type systems that work by inference, rather than
annotation checking, often do not explicitly "check".  This phenomenon
is why they sometimes provide incomprehensible type errors.  (I can
explain this in a bit more detail if anyone cares.)

Shriram