What is Expressiveness in a Computer Language

[Pascal Costanza]

David Hopwood wrote:
> Pascal Costanza wrote:
>> Rob Thorpe wrote:
>>> Pascal Costanza wrote:
>>>> Matthias Blume wrote:
>>>>> Pascal Costanza <pc at p-cos.net> writes:
>>>>>
>>>>>> (slot-value p 'address) is an attempt to access the field 'address in
>>>>>> the object p. In many languages, the notation for this is p.address.
>>>>>>
>>>>>> Although the class definition for person doesn't mention the field
>>>>>> address, the call to (eval (read)) allows the user to change the
>>>>>> definition of the class person and update its existing
>>>>>> instances. Therefore at runtime, the call to (slot-value p 'adress)
>>>>>> has a chance to succeed.
>>>>> I am quite comfortable with the thought that this sort of evil would
>>>>> get rejected by a statically typed language. :-)
>>>> This sort of feature is clearly not meant for you. ;-P
>>> To be fair though that kind of thing would only really be used while
>>> debugging a program.
>>> Its no different than adding a new member to a class while in the
>>> debugger.
>>>
>>> There are other places where you might add a slot to an object at
>>> runtime, but they would be done in tidier ways.
>> Yes, but the question remains how a static type system can deal with
>> this kind of updates.
> 
> It's not difficult in principle:
> 
>  - for each class [*], define a function which converts an 'old' value of
>    that class to a 'new' value (the ability to do this is necessary anyway
>    to support some kinds of upgrade). A default conversion function may be
>    autogenerated if the class definition has changed only in minor ways.

Yep, this is more or less exactly how CLOS does it. (The conversion 
function is called update-instance-for-redefined-class, and you can 
provide your own methods on it.)

>  - typecheck the new program and the conversion functions, using the old
>    type definitions for the argument of each conversion function, and the
>    new type definitions for its result.

The problem here is: The program is already executing, so this typecheck 
isn't performed at compile-time, in the strict sense of the word (i.e., 
before the program is deployed). It may still be a syntactic analysis, 
but you don't get the kind of guarantees anymore that you typically 
expect from a static type checker _before_ the program is started in the 
first place.

(It's really important to understand that the idea is to use this for 
deployed programs - albeit hopefully in a more structured fashion - and 
not only for debugging. The example I have given is an extreme one that 
you would probably not use as such in a "real-world" setting, but it 
shows that there is a boundary beyond which static type systems cannot 
be used in a meaningful way anymore, at least as far as I can tell.)

>  - have the debugger apply the conversions to all values, and then resume
>    the program.

In CLOS, this conversion is defined as part of the language proper, but 
this is mostly because Common Lisp doesn't make a sharp distinction 
between debugging capabilities and "regular" language features. (I think 
it's a good thing that there is no strong barrier against having 
debugging capabilities in a deployed program.)


> [*] or nearest equivalent in a non-OO language.


Pascal

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