What is Expressiveness in a Computer Language

[Pascal Costanza]

Matthias Blume wrote:
> Pascal Costanza <pc at p-cos.net> 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.

I am not arguing against static type systems. I am just responding to 
the question what the things are that you cannot do in statically typed 
languages.

> [ ... ]
> 
>> 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.

Maybe. The interesting question then is whether you can express the 
kinds of dynamic updates that are relevant in practice. Because a static 
type system always restricts what kinds of runtime behavior you can 
express in your language. I am still skeptical, because changing the 
types at runtime is basically changing the assumptions that the static 
type checker has used to check the program's types in the first place.

For example, all the approaches that I have seen in statically typed 
languages deal with adding to a running program (say, class fields and 
methods, etc.), but not with changing to, or removing from it.

>>> 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.

...and the "translate the date where necessary" approach is essentially 
triggered by a dynamic type test (if value x is of an old version of 
type T, update it to reflect the new version of type T [1]). QED.


Pascal

[1] BTW, that's also the approach taken in CLOS.

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/