David Hopwood wrote: > Pascal Costanza wrote: >> Rob Thorpe wrote: >>> Pascal Costanza wrote: >>>> Matthias Blume wrote: >>>>> Pascal Costanza <[EMAIL PROTECTED]> 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/ -- http://mail.python.org/mailman/listinfo/python-list
