Re: copy-on-write (was: globals considered harmful)

[janeely@fedex.com (Joel Neely (Joel))]

By way of introduction, I'm a NewtonScript programmer who's trying to come
up to speed on SELF as conceptual background; I'll apologize in advance for
any non-SELF-standard terminology on my part.

> Interestingly enough, NewtonScript (the programming language used on
> the Apple Newton) has "copy on write" (COW) slots.  One reason for
> including COW (as I understand it, I'm not a Newton programmer) was to
> save space: clones only need to hold changed slots, not all slots.  In
> the Newton, the prototype's slots can even be in ROM (no prototype
> corruption problem here :-), further saving precious RAM.

Application prototypes are treated as logical ROM, regardless of where
they are stored.  As you stated, dynamic frames (at "run time") only need
slots for modified values/methods; storing a value in a non-existent slot
of a frame causes the slot to be created on the fly (whether previously
inherited or totally virgin).  One can get both shared and private data
by using a dynamic frame as the proto for other dynamic frames, then
explictly modifying slots in the dynamic proto to make shared changes.

> The problem with COW is that there's no straightforward efficient
> implementation...

By efficient, I assume you mean essentially constant-time access.  I suspect
(without much hard evidence, I quickly add) that the NewtonScript interpreter
may be using a linked structure (perhaps akin to the classic LISP a-list?) to
represent a frame.  This certainly avoids the need to copy the entire object
and update inbound references, but at the cost of more work in resolving each
frame.slot reference.

The definition of NewtonScript explicitly forbids the programmer from making
any assumptions re the "layout" of an object, including the order of slots in
a frame.  In fact, two executions of the statement

  foreach SlotName, SlotValue in JRandomFrame do
    /* ...some action on every SlotName, SlotValue pair in JRandomFrame */

aren't guaranteed to iterate over the slots in the same order.  I infer from
this that frame objects are fairly dynamic creatures...

At any rate, thanks for stimulating thoughts...
-jn-