David Hopwood wrote: > Marshall wrote: >> Chris Smith wrote: >>> Marshall <[EMAIL PROTECTED]> wrote: >>> >>>> I think what this highlights is the fact that our existing terminology >>>> is not up to the task of representing all the possible design >>>> choices we could make. Some parts of dynamic vs. static >>>> a mutually exclusive; some parts are orthogonal. >>> Really? I can see that in a strong enough static type system, many >>> dynamic typing features would become unobservable and therefore would be >>> pragmatically excluded from any probable implementations... but I don't >>> see any other kind of mutual exclusion between the two. >> Well, it strikes me that some of what the dynamic camp likes >> is the actual *absence* of declared types, or the necessity >> of having them. > > So why aren't they happy with something like, say, Alice ML, which is > statically typed, but has a "dynamic" type and type inference? I mean > this as a serious question.
Note: I haven't yet worked with such a language, but here is my take anyway. A statically type language requires you to think about two models of your program at the same time: the static type model and the dynamic behavioral model. A static type system ensures that these two _different_ (that's important!) perspectives are always in sync. This is especially valuable in settings where you know your domain well and want to rely on feedback by your compiler that you haven't made any mistakes in encoding your knowledge. (A static type system based on type inferencing doesn't essentially change the requirement to think in two models at the same time.) A dynamically typed language is especially well suited when you don't (yet) have a good idea about your domain and you want to use programming especially to explore that domain. Some static typing advocates claim that static typing is still suitable for exploring domains because of the compiler's feedback about the preliminary encoding of your incomplete knowledge, but the disadvantages are a) that you still have to think about two models at the same time when you don't even have _one_ model ready and b) that you cannot just run your incomplete program to see what it does as part of your exploration. A statically typed language with a dynamic type treats dynamic typing as the exception, not as the general approach, so this doesn't help a lot in the second setting (or so it seems to me). A language like Common Lisp treats static typing as the exception, so you can write a program without static types / type checks, but later on add type declarations as soon as you get a better understanding of your domain. Common Lisp implementations like CMUCL or SBCL even include static type inference to aid you here, which gives you warnings but still allows you to run a program even in the presence of static type errors. I guess the feedback you get from such a system is probably not "strong" enough to be appreciated by static typing advocates in the first setting (where you have a good understanding of your domain). 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
