PEP 3107 and stronger typing (note: probably a newbie question)

[Alex Martelli]

kaens <apatheticagnostic at gmail.com> wrote:

> On 6/20/07, Diez B. Roggisch <deets at nospam.web.de> wrote:
> 
> > That is exactly the problem - there is no "some more" static typing.
> > There is static typing - or not. You can't have it "just a bit".
> 
> Couldn't a language be made so that if you declared a variable like, say:
> 
> string foo = "I'm a string"
> 
> it would be a string, and always a string, and if you declared a variable like
> 
> foo = "i'm a dynamic variable"
> 
> it would be considered dynamic?

It would surely be possible to design a language like that, yes.  I
suspect that, if you wanted to have both names 'constrained to a type'
and others 'not constrained', it would be better to have more symmetry
between the two situations (e.g., the "duck" type in Boo); but many
languages exist to prove that inferior design choices are often taken.


> This doesn't seem like it would be too hard to add in to a language
> that already had dynamic typing (But then again, I am inexperienced -
> although interested in - language design).

It would be extremely cumbersome to start from the implementation of a
language with dynamic typing and extend it to allow the static kind --
each and every name (and item of a container, etc, etc) would have to
carry around an extra pointer to a typechecking function (possibly null
for names that must not be checked).  You'd have to carry the whole
mechanism around at runtime since many assignments could in fact not be
checked statically, of course -- consider assigning a "dynamic"
[unchecked] name to a "static" [checked] one, for example; but, more:

class Foo: ...

class Bar: ...

static Foo foo

static Bar bar

...

foo = bar

this kind of thing would also have to be checked at runtime, since there
might be around a

class FooBar(Foo, Bar): ...

and bar might validly be an instance of FooBar -- therefore ALSO an
instance of Foo, thus validly assignable to foo.

Basically, absent the kind of static analysis that you'd do for type
inferencing (study Boo, SML, or Haskell, to learn more about type
inferencing), VERY few assignments could be tagged as invalid at
compile-time in a language with multiple inheritance.  Badly designed
static languages (ones without type inferencing) often try to hide that
by forcing the programmer to be redundant, e.g. in specifying a "cast",
but even then runtime checks are often necessary.  E.g., even in Java,

Foo foo;
Bar bar;
...
bar = (Bar) foo;

implies a runtime check if either Foo or Bar is an interface (and
well-written OO programs should use interfaces, *NOT* concrete classes,
more often than not: cfr the classic "Design Patterns" book, or Lakos'
excelent book on large scale software in C++, for more about that).

In short, if you really want to avoid (as far as possible) runtime
checks, you should really use a language designed for type inferencing
(Boo is, and in some other ways it's reminiscent of Python; however
there are far more books &c for other languages such as SML and
Haskell).  Or, you could read Robert Martin's classic essay at
<http://www.artima.com/weblogs/viewpost.jsp?thread=4639> and ponder 
whether Uncle Bob might not have a point...


Alex