🚀 go-pugleaf

I wonder if we can raise the level of the dicussion 
on static vs dynamic types to consider more generally where
static typing fails to be sufficient or convenient, and why.

I am also interested in the various ways languages that support
*optional* static typing limit the extent of static typing one can do,
and why.  First of all which languages support optional static typing?

I would guess that static typing is made optional in some languages
because the designers recognized that static typing does not handle
all typing situations, and thus dynamic typing (or, alternatively,
C-like void typing) is a useful analog of the goto statement.
But given optional static typing, the language designers could then 
get lazy and not provide sufficient static typing capability for even
well known situations.

One case of optional static typing that I am aware of is in
Objective-C.  And one limitation I have come up against is the static
typing of mutually recursive instance variable types.  An instance
variable in each class is of type pointer to an instance of the other
class.  The problem comes in somehow declaring each class before the
other is declared.  Here is an example:

----- file A.h ----------
// interface of class A

#include "B.h"   // A needs to include B's interface

@interface A:Object
{
	B *b;   // instance variable b is a pointer to B
	...
}

----- file B.h ----------
// interface of class B

#include "A.h"   // B needs to include A's interface  <-- *ERROR*

@interface B:Object
{
	A *a;   // instance variable a is a pointer to A
	...
}

In C++ you could handle this situation by declaring "extern class A"
and "extern class B" instead of including A.h and B.h.  Objective-C
provides no such solution, that I could discover at least.  One is
forced to declare either a or b as just a generic "id" to break the
circularity.  This is simply a silly limitation of the language, but I
am curious to learn of other such examples.

I suppose the problem of hetrogeneous arrays (a realistic application
is where the types of elements and the functions to be applied to them
are not known until runtime) is another area where static typing
systems fall short of the ideal.  A union of types would be better
when it is appropriate than requiring either dynamic typing or
unwieldy static typing and (most likely) multiple inheritance.

Homogeneous generic types are not handled well in some languages,
in that the base type(s) may not be specified so that instances are
suitably constrained.

Here are some more examples:

From: brm@neon.Stanford.EDU (Brian R. Murphy)
> For example, I can't I write a function which returns
> either a boolean or an integer in a complex way.  I can't write my own
> Y combinator.  I can't write a function which allows either a sequence
> of functions which range over numbers or a sequence of numbers as an
> argument.

What are some other categories of problems that don't fit in existing
static typing systems?  Is it possible to come up with a "fix" for
these problems in the ideal language, or will dynamic typing always be
"necessary", like goto is.  Can we organize these and maybe learn
something about the problem?

Dan LaLiberte
National Center for Supercomputing Applications
liberte@ncsa.uiuc.edu