Re: [Chicken-hackers] [PATCH] Fix #1136 and a question about type specialisation

[Felix Winkelmann]

>> I'm unsure how to fix this.  Is it fixable at all?  Is it worth fixing?
> 
> The only thing I can think of is for the scrutinizer to pre-check for
> a call to object-become! and disable itself.  The trouble is that the
> effects may be pervasive to anywhere in the code, given the power of
> call/cc to execute code out of order.

That's correct. As "object-become!" can mutate any value in arbitrary
ways, and thus makes any assumptions about variable types
invalid. Nothing can be done about it, but I don't consider this
critical, as "object-become!"  is seldom used. And it's not hard in
general to confuse the scrutinizer by using various low-level hacks.

> 
>> Perhaps we should get rid of object-become!; I'm not sure how useful
>> it is (only one egg uses it: protobuf), and it just causes trouble.
> 
> An identical facility is used in Smalltalk when a class is redefined,
> to allow existing instances to conform to the new class definition.
> For each existing instance, a new instance is created, and then the new
> objects are made to replace the old.

It is also used in Smalltalk for object-persistence (filing in objects
that are represented by a "proxy" object).

"object-become!" is one of those features that are seldom used, but
for which no replacement exists: it allows changing an object without
changing its identity. The "utf8" egg uses this for modifying strings
in-place that grow in size due to "string-set!".


felix