Self-interest February 1995

self-interest@lists.selflanguage.org

9 participants
9 discussions

Self 4.0 Alpha
by John.Maloney＠Eng.Sun.COM 15 Feb '95

15 Feb '95

The Self group proudly announces that Self 4.0 is now available for alpha testing. As soon as any remaining bugs have been shaken out, we will be making this release publically available; watch this space for an announcement! Meanwhile, if you are brave, friendly, have some familiarity with Self and would like to help us by testing the system, please contact john.maloney(a)sun.com He will put you on our list of alpha testers and send you a password that you can use to download Self 4.0. -- Mario Wolczko, David Ungar, Randall B. Smith, John Maloney Release 4.0 Highlights o Release 4.0 contains an entirely new user interface and programming environment designed for "serious" programming. This environment enables the programmer to create and modify objects entirely within the environment, and then save the object into files for distribution purposes. You no longer have to edit source files using an external editor (indeed, it is discouraged). The metaphor used to present an object to the user is that of an outliner, allowing the user to view varying levels of detail. Also included in the environment is a graphical debugger, and tools for navigation through the system. o A new version of the transporter, a facility for saving objects structure into files, has been used to modularize the system. The programming environment presents an interface to the module system which allows for straightforward categorization of objects and slots into modules, and the mostly-automatic saving of modules into files. Handwritten source files have almost completely disappeared. o The environment has been constructed using a new, flexible and extensible user interface construction kit, based on morphs. Morphs are flexible and general-purpose user interface components. An extensive collection of ready-built morphs is provided in the system, together with facilities to inspect, modify and save them to files. We believe the morph-based substrate provides an unprecedented degree of openness and flexibility in user interface construction. o Significant engineering has been done on the Virtual Machine to reduce the memory footprint and enhance memory management. For example, a 4.0 system containing a comparable collection of objects to that in the 3.0 release requires 40% less heap space. A SELF-level interface to the memory system is now available that enables SELF code to be notified when heap space is running low, and to expand the heap. o The privacy syntax has been removed; in the previous release it was accepted but privacy was not enforced. The concept of privacy still exists, and is visible in the user interface, but is supported entirely through the annotation system. SELF currently runs on SPARC-based Sun workstations using Solaris 2.3 or later, or SunOS 4.1.x. The compiler is an improved version of the one used in 3.0. System requirements To run SELF you will need a SPARC-based Sun computer or clone running SunOS 4.1.X or Solaris 2.3 or 2.4. To use the programming environment you will need to run X Windows version 11 or OpenWindows on an 8-bit or deeper color or gray-scale display. The X server need not reside on the same host as SELF. The SELF system requires at least 20Mb of physical memory to run well (in addition to that required by the operating system and window system), and at least 32 Mb of additional swap space. This means that the host machine should have at least 32 Mb of RAM, and preferably more, as Unix and X together typically take 12Mb of memory. If you use a machine with 32 - 48 Mb you should use the special version of the system for these machines (the small configuration) and close down all other non-essential programs, otherwise SELF will page heavily. Even a single clock or mail reader can make a difference you should have only X or OpenWindows, a shell, and SELF. The user interface makes substantial demands of the X server. A graphics accelerator (such as a GX card) improves the responsiveness of the user interface significantly, and therefore we recommend that you use one if possible.

1 0

inheritance semantics in Self 4.0
by Marty Plotkin 08 Feb '95

08 Feb '95

I've seen a number of references to various changes that have been made to Self's inheritance semantics since Self 3.0. For example, elimination of parent priorities, a new theory of slot privacy, new idioms for sharing behavior. I gather that the changes are slated to appear in Self 4.0. I've tried to locate a written description of the new semantics, perhaps including an outline of the latest lookup algorithm, but I haven't found it. Am I missing something? If so, I'd appreciate a pointer. Or perhaps someone in the know would be willing to post a summary. Thanks! --Marty

2 1

Re(2): ambiguous inheritance question
by jecel＠lsi.usp.br 08 Feb '95

08 Feb '95

On 1 Feb 1995 18:04:48 -0800 "David Ungar" <david.ungar(a)Sun.COM> wrote: > By the way, I'm intrigued by a different style of programming, > but unfortuneatly our VM doesn't quite support it efficiently enough > to convert over the whole system. It is a good idea to think about these thing anyway. They might end up in other people's languaged even if they don't fit Self to well. > In this style you lump together methods and data slots, > and use data parents (with single inheritance!) instead of copy-down. > > so a point has: > > parent, +, x, y in it. > > and a colored point has > > parent* <- aPoint > color <- ... > <other methods> > > in it. This looks very interesting. But... 1) What does clone mean here? I would guess that you would have to "deep" clone the object and all of its data parents. Would this be right? We can do this today by adding these slots to traits clonable: dataParent = (). clone = ( _Clone dataParent: dataParent clone ). dataParent: obj = ( ^ self ). There are bugs in this, but you get the idea. Any object with and assignable slot called dataParent would automatically clone it whenever itself was cloned. This stops at the first "normal" object. 2) Do we want to get rid of traits? Maybe. Traits make things more complicated and less concrete, but they are used for: A) Saving space. This is not true in any practical implementation of Self. In fact, dividing an object into prototype and traits makes it about 11 words larger ( though all of this overhead is shared with all of its clones ). B) Changing shared behaviour. If you change a method in a point, no other points are affected. When I programmed my CMOS simulator in Self 1.0 this didn't bother me and I wrote a lot of methods in the objects themselves rather than in traits. That is because I would throw away all objects and clone them all over when re-reading a Self script. Traits allow you to change an application while it is running ( or being debugged ), just like Smalltalk does. On the other hand, no system allows you to change the format of the objects without first getting rid of all instances. C) Naming a useful concept. Separating prototypes from traits allows you to inherit abstract interfaces without also inheriting implementation. 3) Can we get by without multiple inheritance? Actually, though I agree getting rid of parent priorities and default conflict resolution was the right choice, it is now harder to use multiple inheritance for anything other than mixins. We don't need MI to get around a type system like C++ does, so I don't know how much I would miss it if we didn't have it at all. But I hate having to chose whether a string is a collection or a magnitude. > The catch is that the parent slot of colored point > causes a bunch of inefficiency today, otherwise > I would be doing it in a big way. I have to admit that this is much more my style too. > But there are ways to make this work well ( > one was suggested by Craig a long time ago and I haven't > forgotten). I don't see much of a problem here. Just inline all of the data parent methods as if it were a constant parent. When you send parent:, just check if the new parent has the same map as the old. In the rare ( if this were the normal style, of course, not currently ) case where it is not you have to recompile stuff to look more like it does today. > I really think it would be better than what we have. I am not sure, but I will always vote for simplicity. > Maybe for Self 5.0, if and when.... I don't know what is happening over there ( some rumors in comp.lang.smalltalk, though ), but you can be sure it is a case of "when". The good new is that there *will be* a Self 5.0. The bad news is that it will be called VisualBasic 7.0 ;-) -- Jecel

1 0

ambiguous inheritance question
by Ivan Moore 03 Feb '95

03 Feb '95

Dear Self interest group, What are peoples opinions on the following: given an inheritance hierarchy as below: A / \ B C \ / D where B and C are parents of D, and A is the parent of B and C, If A defines slot m, and B defines its own version of slot m, if you send D the message m, you get an ambiguous selector error (as expected). How about if D got the m in B, because it does override the one in A, after-all. What I mean is that the m in B overrides the very same slot m that D inherits via C. If it was a different m that it was overriding I'd be totally happy with an ambiguous selector error. What do you think? Would the proposed scheme invite obscure bugs? Would it be difficult to understand? You may think that this sort of situation doesn't occur often enough to be a problem - maybe true - but dispite that, what do you think? Ivan.

3 2

Re: dynamic delegation / use
by chambers＠cs.washington.edu 03 Feb '95

03 Feb '95

Cecil has a more static object structure, in part to support static type checking (although I believe a type system rich enough to support some kind of dynamic inheritance is feasible; Luca Cardelli may already have developed such a system). But Cecil does include a more structured kind of dynamic inheritance, where a class can have dynamic subclasses in a sense. See my Predicate Classes paper in ECOOP'93 (or on the Cecil web page). -- Craig Chambers

1 0

dynamic delegation / implementation
by Guenter Kniesel 02 Feb '95

02 Feb '95

Dear Self team. One of the older implementation papers mentioned that dynamic delegation is not optimized by the Self compiler. Is this still true? What IS being done in the case of DD? Although I've read a lot about Self, I found almost no mentionings of dynamic delegation in implementation papers. Is there a paper that I might have missed? I'd be interested even in papers describing no solutions, just problems you found in conjunction with DD. Do you have any experience / mesurements how costy DD is? Thanks in advance. Guenter

1 0

dynamic delegation / use
by Guenter Kniesel 02 Feb '95

02 Feb '95

Dear Self programmers. (I mean those who, unlike myself :-), have written "real" Self programs). I'm interested in the _practical_ use of dynamic delegation (DD). - How often do you use DD? - Would lack of DD be a serious drawback for your applications? - Are there typical examples or scenarios for the use of DD? - Are there programming techniques that are typically employed in conjunction with DD / that rely on the availability of DD? Would anyone from the Cecil group like to add his view of DD? Is DD missing from Cecil because it wasn't considered useful, or "only" for technical reasons, e.g. to ease having a static type system? Guenter

1 0

Re(2): ambiguous inheritance question
by David Ungar 02 Feb '95

02 Feb '95

By the way, I'm intrigued by a different style of programming, but unfortuneatly our VM doesn't quite support it efficiently enough to convert over the whole system. In this style you lump together methods and data slots, and use data parents (with single inheritance!) instead of copy-down. so a point has: parent, +, x, y in it. and a colored point has parent* <- aPoint color <- ... <other methods> in it. The catch is that the parent slot of colored point causes a bunch of inefficiency today, otherwise I would be doing it in a big way. But there are ways to make this work well ( one was suggested by Craig a long time ago and I haven't forgotten). I really think it would be better than what we have. Maybe for Self 5.0, if and when.... Dave ------ From: Randy Smith, Tue, Jan 31, 1995 ------ > > given an inheritance hierarchy as below: > > A > / \ > B C > \ / > D > > where B and C are parents of D, and A is the parent of B and C, > > If A defines slot m, and B defines its own version of slot m, if you send D > the message m, you get an ambiguous selector error (as expected). > > How about if D got the m in B, because it does override the one in A, > after-all. What I mean is that the m in B overrides the very same slot m that D > inherits via C. If it was a different m that it was overriding I'd be totally > happy with an ambiguous selector error. > > What do you think? Would the proposed scheme invite obscure bugs? Would it > be difficult to understand? You may think that this sort of situation doesn't > occur often enough to be a problem - maybe true - but dispite that, what do > you think? > > Ivan. > > I believe this is what we call "unordered up to (but not including) join" semantics. I think Craig Chambers, who was with the Self group at the time we were rethinking MI, was an advocate for putting this style of MI in Self.(comment Craig?) It's something we talked about, and it does have the advantage of allowing many cases (but not all cases, I think) of "data parents." There are still other concerns about data parents ... Self used to have them many years ago, but they were kind of nice in some ways. Anyway, the thinking was more on the side of radical simplification: making MI as easy as possible to understand. However unordered up to join is maybe not all THAT complicated, and because it allows this useful data parent thing, maybe it is a good idea. Instead of data parents, today we "copy down" at creation time, and that yields its own set of complications. Interesting that you hit upon this idea! --Randy P.S.: In unorderd up to join, this below would be an error, whereas in the old days, B and C could be given different priorities, and therefore data parents, who often appear in graphs like this, were easier to support. A(m) / | / | / | B(m) C(m) | / | / | / | / D

1 0

Re: ambiguous inheritance question
by David Ungar 02 Feb '95

02 Feb '95

Great question--we almost implemented it that way at Stanford. I think it would be very interesting to try living with it-- could be really bad, could be really good--I have a high degree of uncertainty. It does remind me of some of the bad mistakes I have made in the past. - Dave ------ From: Ivan Moore, Tue, Jan 31, 1995 ------ Dear Self interest group, What are peoples opinions on the following: given an inheritance hierarchy as below: A / \ B C \ / D where B and C are parents of D, and A is the parent of B and C, If A defines slot m, and B defines its own version of slot m, if you send D the message m, you get an ambiguous selector error (as expected). How about if D got the m in B, because it does override the one in A, after-all. What I mean is that the m in B overrides the very same slot m that D inherits via C. If it was a different m that it was overriding I'd be totally happy with an ambiguous selector error. What do you think? Would the proposed scheme invite obscure bugs? Would it be difficult to understand? You may think that this sort of situation doesn't occur often enough to be a problem - maybe true - but dispite that, what do you think? Ivan.

1 0

2024

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 February 1995