What is Expressiveness in a Computer Language

Pascal Costanza pc at p-cos.net
Wed Jun 28 16:44:31 CEST 2006

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.


3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006

More information about the Python-list mailing list