Joachim Durchholz wrote: > Pascal Costanza schrieb: >> (It's really important to understand that the idea is to use this for >> deployed programs - albeit hopefully in a more structured fashion - >> and not only for debugging. The example I have given is an extreme one >> that you would probably not use as such in a "real-world" setting, but >> it shows that there is a boundary beyond which static type systems >> cannot be used in a meaningful way anymore, at least as far as I can >> tell.) > > As soon as the running program can be updated, the distinction between > "static" (compile time) and "dynamic" (run time) blurs. > You can still erect a definition for such a case, but it needs to refer > to the update process, and hence becomes language-specific. In other > words, language-independent definitions of dynamic and static typing > won't give any meaningful results for such languages. > > I'd say it makes more sense to talk about what advantages of static vs. > dynamic typing can be applied in such a situation. > E.g. one interesting topic would be the change in trade-offs: making > sure that a type error cannot occur becomes much more difficult > (particularly if the set of available types can change during an > update), so static typing starts to lose some of its appeal; OTOH a good > type system can give you a lot of guarantees even in such a situation, > even if it might have to revert to the occasional run-time type check, > so static checking still has its merits.
I am not opposed to this view. The two examples I have given for things that are impossible in static vs. dynamic type systems were intentionally extreme to make the point that you have to make a choice, that you cannot just blindly throw (instances of) both approaches together. Static type systems potentially change the semantics of a language in ways that cannot be captured by dynamically typed languages anymore, and vice versa. There is, of course, room for research on performing static type checks in a running system, for example immediately after or before a software update is applied, or maybe even on separate type checking on software increments such that guarantees for their composition can be derived. However, I am not aware of a lot of work in that area, maybe because the static typing community is too focused on compile-time issues. Personally, I also don't think that's the most interesting issue in that area, but that's of course only a subjective opinion. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
