David Hopwood wrote: > Pascal Costanza wrote: >> David Hopwood wrote: >>> Pascal Costanza wrote: >>>> David Hopwood wrote: >>>>> Marshall wrote: >>>>> >>>>>> The real question is, are there some programs that we >>>>>> can't write *at all* in a statically typed language, because >>>>>> they'll *never* be typable? >>>>> In a statically typed language that has a "dynamic" type, all >>>>> dynamically typed programs are straightforwardly expressible. >>>> What about programs where the types change at runtime? >>> Staged compilation is perfectly compatible with static typing. >>> Static typing only requires that it be possible to prove absence >>> of some category of type errors when the types are known; it >>> does not require that all types are known before the first-stage >>> program is run. >> Can you change the types of the program that is already running, or are >> the levels strictly separated? > > In most staged compilation systems this is intentionally not permitted. > But this is not a type system issue. You can't change the types in a > running program because you can't change the program, period. And you > can't do that because most designers of these systems consider directly > self-modifying code to be a bad idea (I agree with them).
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. There are at least systems that a lot of people rely on (the JVM, .NET) that achieve runtime efficiency primarily by executing what is essentially self-modifying code. These runtime optimization systems have been researched primarily for the language Self, and also implemented in Strongtalk, CLOS, etc., to various degrees. 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. > 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. 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