Self-interest March 1994

self-interest@lists.selflanguage.org

19 participants
25 discussions

copy-on-write
by David.Ungar＠Eng.Sun.COM 25 Mar '94

25 Mar '94

I have just skimmed the discussion, but nevertheless am ready to stir things up! I would propose that copy-on-write is implementable, but yields an object model whose strengths and weaknesses are complimentary to Self's. Self cleanly separates shared from private information, and allows for shared state in a straightforward way. A Lieberman-style system (with copy-on-write) avoids the non-concrete traits problem but makes it harder to express shared state-- how do you know when NOT to copy-on-write? Personally, the next language I work on ;-) is going to have a much simpler model; I suspect both are too complicated. -- Dave (responsible for many of the overcomplexities in Self and have learned the hard way) Ungar

1 0

Re: Floats in self.
by urs＠cs.stanford.edu 25 Mar '94

25 Mar '94

> I was wondering what happens when a float is tagged. Is the mantissa > truncated and then tagged: No, we take two bits from the exponent (reducing the range of floats to about 10**9) so that the precision remains the same. We know that this solution isn't ideal; Self should probably have double-precision floats and possibly float vectors. So far floats just haven't reached the top of our list... -Urs

1 0

Re: copy-on-write
by janeely＠fedex.com 25 Mar '94

25 Mar '94

> Given their emphasis on space over speed, and given the relatively > small amount of RAM, I would expect ... > that they just make a copy that extends the object by the extra slot, > then do a pass over memory to redirect all pointers to the object to > refer to the new copy. That very well may be... but my experiments to date seem to indicate that the address for a frame doesn't seem to change simply because slots have been added, but does seem to change after events that would imply that garbage has been collected. (more snooping remains to be done...) -jn-

1 0

Re: copy-on-write (was: globals considered harmful)
by urs＠cs.stanford.edu 24 Mar '94

24 Mar '94

> [...] > I think there are definite advantages to unifying this behaviour by > providing a mechanism for copy-on-write on a per-slot basis. For > example, in a word-processor I might want all paragraphs to appear in > a default typeface unless specifically overridden by the user; if the > default is changed all paragraphs which have not been so overridden > should reflect that change; and a paragraph-object with an overridden > "typeface" ("style", whatever) slot should be revertable to the default > behaviour by deleting the slot. I think that is what Alexis was getting at. 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. The problem with COW is that there's no straightforward efficient implementation. For example, if an assignment grows an object, the implementation has to make up a new object and redirect all pointers to the old object. That's only fast if you use indirect pointers (i.e., an object table), which is acceptable for an interpreter but slows down a compiled system quite a bit. However, there may be some clever trick to implement COW efficiently. Sounds like a Ph.D. thesis to me... :-) -Urs

1 0

Re: globals considered harmfull.
by alex＠XAIT.Xerox.COM 24 Mar '94

24 Mar '94

Hi folks -- This present discussion dovetails with something I have been thinking about exploring for some time -- the idea is to have a stack or tree of contexts that provide essentially copy-on-write semantics on objects; this would allow one to do exploratory computations and then unwind any object changes. OO meets AI? (The actual idea is to provide the appearance of copy-on-write in a hopefully efficient way. Using surrogate objects and parent pointers can go a long way. The hard part is efficiently dealing with object dispatch in a given context, I would hazard.) This idea is kind of nebuluous and there are issues in how one would determine how to remember (or define) the "result" of the computation so it too is not unwound. It seems to me that a multi-user system would introduce many of the same access control mechanisms that contexts would. (E.g. the green user can only modify the green objects. The question becomes what happens when the green user tries not modify a red object. Do we create a substitute green object? Do we throw an exception? Can the user catch the exception, substitute his own object, and restart the computation?) Food for thought. Alexis Layton alex(a)XAIT.Xerox.COM

2 1

Re: copy-on-write (was: globals considered harmful)
by janeely＠fedex.com 24 Mar '94

24 Mar '94

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-

1 0

Re: globals considered harmfull.
by David.Ungar＠Eng.Sun.COM 23 Mar '94

23 Mar '94

>I think that the problem might be best solved by extending the VM to >have restrictions on what processes can change what objects/slots. It >could be ids, groups of ids or whatever. > >This might be prototyped by modifying slots assignment code. > >This potentially allows multiuser ability. > >You could also allow 'different' objects (e.g. lobby) for different >processes (this also allows multiuser ability). This also avoids one >process/user trashing another as well. > >-Ian This is a good idea that has surfaced before--I think it has the germ of something quite powerful! Dave -- Dave

1 0

globals considered harmfull.
by I.R.Woollard＠bnr.co.uk 22 Mar '94

22 Mar '94

Self Style Suggestion: If I want to produce an instance of something, I believe it is better to ask the traits object for it. I propose that most traits objects should respond to a 'new' invocation - it allows the posibility of parameters to determine the contents. - it doesn't preclude having globals as well - a 'new' mixin is easily defined - a lot of traits already have a prototype slot - its less code in the clients, you don't have to use explicit "copy"'s - it is closer to the smalltalk model, hence easier to learn Currently: - accidently forgetting the copy is a real screw up, you end up modifying the prototype -Ian p.s. I'm obviously missing something here... I'm quite prepared to be persuaded... p.p.s. Is there any kind of style guide anywhere? (I have read the User Manual) p.p.p.s. Long term, languages are port or die. How portable *is* Self?

3 4

Re: globals considered harmfull.
by David.Ungar＠Eng.Sun.COM 22 Mar '94

22 Mar '94

It's been a lot of fun to follow this discussion. I think what started it was Ian's realization of the "corrupted prototype problem" as we call it. And this is a real problem that hints at a problem with the language. But, I am not ready to give up and ask the traits object to create a new object. For one thing, this is less concrete, as the traits object must get some additional knowledge from somewhere hidden. Also, there is a style of programming in which you do not create traits--even for multi-"instance" objects, and I would not want to discourage it. (Traits are still used when you need to change inherited info on-the-fly, i.e. for long-lived objects). One way to mitigate the prototype-corruption problem that I am seriously considering would be to make "globals" no longer be a parent and to change its name to something shorter, like "the". The drawback: every time you refer to a prototype, you would have to say "the point copy" instead of "point copy". The benefits: slightly harder to forget copy, and better for showing all of an object's inherited attributes in a single place. (Solves a problem that is facing Kevo). Anyway, thanks for an interesting discussion! -- Dave

1 0

Self Mosaic home page
by urs＠cs.stanford.edu 19 Mar '94

19 Mar '94

Thanks mostly to Bay-Wie Chang, Self now has a Mosaic home page, http://self.stanford.edu All of our material continues to be available via ftp, but the Mosaic interface is definitively friendlier (e.g., it has an online bibliography and paper abstracts). Enjoy! -Urs

1 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest March 1994