RE: dynamic vs. static typing

["Anton van Straaten" <address@hidden>]

Joe Marshall wrote:
> "Anton van Straaten" <anton@appsolutions.com> writes:
>
> > An ideal typesystem should allow static expression or detection
> > of the things that can be known statically, without significantly
> > inhibiting our ability to manipulate things that can only be known
> > dynamically.
>
> This sounds reasonable...

Oh good - I was half-expecting someone to point out how unrealistic it was.

> > Pure DT languages say "we dunno how to provide that, so we're not
> > going to offer any static analysis whatsoever".
>
> ...but this is a caricature.  Any compiled language does *some*
> sort of static analysis.
...
> DT languages say ``no one can statically analyze all uses of feature
> X, but we *can* dynamically ensure that any particular usage of
> feature X will be checked for correctness.  Since it can be proven
> that complete static analysis is impossible so we will still need the
> dynamic tests for when the static analysis cannot decide, and since
> even in those cases where it *is* possible, it offers no more safety
> than already exists, why bother?''

My caricature was shorter and snappier, but I'll concede that your statement
is more accurate.

> The answer, of course, is that the sooner you find out something,
> the better.
>
> So it is a tradeoff:  reduced language power vs. redundant
> analysis vs. early answers.

One way to address this tradeoff is with optional early analysis that warns
rather than prevents.

> > I don't believe that this choice, as pragmatic as it may be,
> > represents the ultimate in language capabilities.
>
> I agree.  There is a lot more that could be statically checked.
> Nonetheless, I prefer to start from the `pure DT' side and add static
> analysis rather than start from the `pure ST' side and add dynamic
> abilities.  I believe that there are far too many interesting programs
> that cannot be statically analyzed.

That's fine with me.  I've mainly been arguing against rejecting the idea of
any type analysis whatsoever, without convincing reasons.  I've defended
existing ST approaches more from the perspective that they can do much more
than some seem to think.  But "type analysis" doesn't have to mean ST as
currently implemented.

One of the first things that I think many pure DT languages could benefit
from would be optional type annotations.  This can support static analysis
tools without necessarily constraining the language at all, i.e. you could
choose to ignore a warning about a type conflict, in the same way that I
tend to blithely ignore warnings like "binding not exhaustive" for pattern
matches when writing ML.  (ML needs more of that! :)  You could even choose
not to run the type-checking tool.  Disallowing type annotations in a
language seems like an unnecessary restriction, which prevents you from
capturing useful information about your program, and prevents you from
performing useful checks.  I'm arguing for a more sophisticated and flexible
approach to types, even in DT languages.

Perhaps optional type annotations could be promoted as "building unit tests
right into your programs!" to tap into the wave of enthusiasm for
test-driven development...  ;)

Anton