Pascal Costanza <[EMAIL PROTECTED]> writes: > Whether you consider something you cannot do with statically typed > languages a bad idea or not is irrelevant. You were asking for things > that you cannot do with statically typed languages.
The whole point of static type systems is to make sure that there are things that one cannot do. So the fact that there are such things are not an argument per se against static types. [ ... ] > Beyond that, I am convinced that the ability to update a running > system without the need to shut it down can be an important asset. And I am convinced that updating a running system in the style of, e.g., Erlang, can be statically typed. >> Note that prohibiting directly self-modifying code does not prevent a >> program from specifying another program to *replace* it. > > ...and this creates problems with moving data from one version of a > program to the next. How does this "create" such a problem? The problem is there in either approach. In fact, I believe that the best chance we have of addressing the problem is by adopting the "replace the code" model along with a "translate the data where necessary at the time of replacement". Translating the data, i.e., re-establishing the invariants expected by the updated/replaced code, seems much harder (to me) in the case of self-modifying code. Erlang got this one right. -- http://mail.python.org/mailman/listinfo/python-list
