>> 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 _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
