kaens <[EMAIL PROTECTED]> wrote: > On 6/20/07, Diez B. Roggisch <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
