Self-interest September 1992

self-interest@lists.selflanguage.org

18 participants
20 discussions

Compiling Self etc.
by R James Noble 17 Sep '92

17 Sep '92

> 1. when i try to compile the VM source code You're compiling the VM source - good on you! I haven't yet had the time or disk space... Let me know how things turn out. > 3. when will there be a native X version of Self that doesn't use Pixrects? I have some limited X support going using a dynamic library. It's been working for most of the year. However, as it's only support for a thesis project I tend to do only the stuff I really need :-) It does work, and a I've sent out a previous small X library which a couple of people used with some success. If you really need this, I can get you a copy of my current work: I'm hoping to put a snapshot on contrib before the end of next month - but I've made those promises before... > thanks! kjx

1 0

Self 2.0.1 released
by Lars.Bak＠Eng.Sun.COM 12 Sep '92

12 Sep '92

Self 2.0.1 is now available from anonymous ftp from self.stanford.edu in the directory Self-2.0.1. This release fixes bugs discovered after sending out release 2.0 and improves stepping in the self debugger by skipping trivial bytecodes. Good luck The Self Group at Sun Microsystems Laboratories, Inc. and Stanford University

1 0

self on Solaris 2.0
by timh＠sunwa.Aus.Sun.COM 10 Sep '92

10 Sep '92

Hi Has anyone looked at/ported Self to Solaris 2.0 See ya round Tim

1 0

Re: MI in SELF
by chambers＠cs.washington.edu 07 Sep '92

07 Sep '92

... > There can be a continum between prototyping languages and systems engineering > languages. A programmer could begin by writing a prototype in Self. If the > user liked it but needed something more solid the programmer could start > turning on the checks, eventually producing a fully type checked program > where all messages were guaranteed a good destination. I find type checking a > good debugging tool. ... > Again I propose completely dividing inheritance into two notions. Genetic > inheritance which has to do with construction and message passing. And > logical inheritance which has to do with type checking and has no relation to > internal structure or message passing. > > -- > cef(a)mwc.com Spelling errors in this document are > 708-291-6700 x119 caused by uucp compression algorithims I've been working on a language named Cecil descended partially from Self which may answer both these points. Cecil supports static type checking, but type declarations are optional. Where omitted, dynamic typing is used. This enables a program to be born in a dynamically-typed prototyping mode, but gradually evolved into a mature production program in part by adding type declarations. Like a few other languages, Cecil distinguishes between subtyping (what you call logical inheritance) and code inheritance (what you call genetic inheritance). Other aspects of Cecil, such as its multiple dispatching base, are described in a paper in ECOOP'92. Cecil is not now a working product. We have an interpreter running for the dynamically-typed core of the language, but the type checking is still being implemented. An efficient, usable implementation is still far in the future. -- Craig Chambers

1 0

MI in SELF
by John.Maloney＠Eng.Sun.COM 04 Sep '92

04 Sep '92

Lee, I'm in the SELF group here at SUN. What you seem to be asking for is sometimes called "behavioral reflection:" the ability of an object to define for itself how messages are looked up. It isn't clear from your message what you want to express that seems to require behavioral reflection. I think there may be ways to use dynamic inheritence to achieve the result you have in mind, by dynamically re-ordering chains of parents. Is the problem that you *cannot* order the parents uniquely? For example, if two parents p1 and p2 both have slots with names m1 and m2 AND you want p1's m1 behavior but p2's m2 behavior, then the parents would have to be re-ordered for each message. If that is your problem, you have several alternatives: a. re-factor your behavior into smaller chunks b. use a "transparent forwarder" object (an object that catches "undefinedSelector" and re-sends the message to the appropriate object). this is pretty close to what you seem to want c. use the reflective facilities to build an object with the right set of slots (Borning used this technique to implement multiple inheritance in Smalltalk) I believe that, however it is implemented, the ability to change an object's behavior dynamically should be used only sparingly, and in highly stylized ways. Otherwise, one can too easily create objects whose behavior is difficult or impossible to predict. -- John

2 1

Re: MI in SEL
by lee＠animal.nrc.com 04 Sep '92

04 Sep '92

> > Lee, > > I'm in the SELF group here at SUN. > > What you seem to be asking for is sometimes called "behavioral reflection:" > the ability of an object to define for itself how messages are looked up. > It isn't clear from your message what you want to express that seems to > require behavioral reflection. I think there may be ways to use dynamic > inheritence to achieve the result you have in mind, by dynamically re-ordering > chains of parents. Is the problem that you *cannot* order the parents > uniquely? For example, if two parents p1 and p2 both have slots with > names m1 and m2 AND you want p1's m1 behavior but p2's m2 behavior, then > the parents would have to be re-ordered for each message. If that is > your problem, you have several alternatives: > > a. re-factor your behavior into smaller chunks > b. use a "transparent forwarder" object (an object that > catches "undefinedSelector" and re-sends the message > to the appropriate object). this is pretty close to > what you seem to want > c. use the reflective facilities to build an object with > the right set of slots (Borning used this technique to > implement multiple inheritance in Smalltalk) > > I believe that, however it is implemented, the ability to change an > object's behavior dynamically should be used only sparingly, and in > highly stylized ways. Otherwise, one can too easily create objects > whose behavior is difficult or impossible to predict. > > -- John Hi John. I do seek a reflective capability. However, in a language with a uniform presentation of behavior and state, I wonder if 'behavioral reflection' is still the appropriate term. I don't have any particular application in mind. I merely speculate that dynamic inheritance, together with a reflective capability, obviates the need for multiple inheritance support on the part of the language. Perhaps simple inheritance is actually more general. You correctly observe that there are cases in which *no* parent ordering will have the desired inheritance. Moreover, by dynamically reordering the parents, we defeat our purpose in having ordered them in the first place. SELF will search the inheritance chain before our object has the opportunity to specify its desired inheritance, so we lose our opportunity for reordering anyway. The 'undefinedSelector:' message cannot help our object since it is delivered only after the inheritance chain has been searched. The 'transparent forwarder' (sometimes termed a 'proxy') is a special case object that has no (or very little) behavior or state of its own. I would hope that a reflective capability could apply more generally. Besides, wouldn't this be a good way to implement proxies? I may not understand what you mean by the 'right set of slots'. I don't think that *any* set of slots is guaranteed to match the messages that might be sent to an object. I can send an arbitrary set by typing them in at the keyboard. I completely agree with your last point. David Ungar expressed a similar concern in his first paper on SELF (how is one *supposed* to program in SELF, anyway?). But since no language is sufficient to make a good programmer of a bad one (axiom here), I believe that any attempt by language developers to constrain or enforce 'correct' programming is misdirected. -- Lee -- Lee Murach Tel: (805) 485-2700 Network Research Corp. FAX: (805) 485-8204 2380 North Rose Avenue Internet: lee(a)nrc.com Oxnard, CA 93030 CompuServe: 71161,651

1 0

prototyping vs systems engineering languages
by Charles Fiterman 03 Sep '92

03 Sep '92

While self is designed as a prototyping language, it has the oppourtunity to be a systems engineering language also. The users of prototyping languages often would like to be able to turn on some lint like rules and turn their prototypes into saleable software without rewriting the world. Also the rules in systems engineering languages are often a good way to find bugs, witness the success of lint. I would like to divide inheritance notions into genetic inheritance and logical inheritance and suggest that self can treat them as totally separate concepts. Genetic inheritance is mearly a convienient way of building things. If you use an existing class "dog" as a good place to start building a new class "cat" it does not mean that a method expecting a "dog" parm can get a "cat" parm. Thus in turning a "dog" into a "cat" the user should be allowed any surgery desired even deleting the "barking" method. Logical inheritance is a way of generalizing methods. If a method expects a parm of class "animal" and "dog" logically inherits from "animal" it only means that the methods of "dog" are compatible with those of "animal" not that "dog" geneticly inherits from "animal" or that their internal structures are in any way similar. The most logical structure for polygons in very different from the most logical structure for squares but a method recieving a polygon should be able to get a square and act on it normally. It should be possable to create "cat" from "dog" genetically and then say that "cat" logically inherits from "animal". In creating classes siblings often have more in common than parents and children. In prototyping mode self would say, fine "cat" logically inherits from "animal". In systems engineering mode it would check for compatible methods and ambiguitys, prompting the user to create a "cat" that could be safely used wherever an "animal" is expected. In systems engineering mode type checking would be done on parms at compile time. In prototyping mode it would be ignored. C++ can't do this because it must rely on children having a structural relation to parents. Self has a unique oppourtunity because it builds code at run time. Allowing logical inheritance graphs to be modified adds new fields of exploration. The real function of new languages like Self IMHO is to open new kinds of thinking. One of the most profitable forms of language extension has been "X is now a first class object.". Logical inheritance graphs can be a first class object, I wonder where that will lead. -- cef(a)mwc.com Spelling errors in this document are 708-291-6700 x119 caused by uucp compression algorithims

1 0

Multiple inheritance in SELF
by lee＠animal.nrc.com 03 Sep '92

03 Sep '92

Hi. I'm a STalker who has only recently become SELFish. I consider prototyping, dynamic inheritance, and uniform access to behavior and state to be important developments in object oriented programming. But I'm surprised that SELF should require explicit support for multiple inheritance. Multiple inheritence provides the only means by which an object in a 'static inheritance' language may inherit capability from more than one parent. When these capability sets intersect, it is encumbent upon the language to resolve the ambiguity. Whatever convention the language employs, the choice is just as static as is the inheritance itself. Ideally, one would hope to choose whatever inheritance is appropriate for the moment (i.e., the current state). Dynamic inheritance provides this facility. Unfortunately, the SELF object never gets the opportunity to choose. The inbound message is dispatched according to a precedence relationship that was established before the message was even sent. Perhaps SELF could be ammended to include a 'default' slot that, if defined, would receive messages that do not match the other slots, and for which the receiver is not the sender. The slot might be occupied by a method that sets the parent, sends the message to self, then resets the parent. Just a thought. Lee -- Lee Murach Tel: (805) 485-2700 Network Research Corp. FAX: (805) 485-8204 2380 North Rose Avenue Internet: lee(a)nrc.com Oxnard, CA 93030 CompuServe: 71161,651

1 0

Re: Persistence and Transactions
by David.Ungar＠Eng.Sun.COM 01 Sep '92

01 Sep '92

Gordon, If you have a chance I would love to hear more about the semantic changes that would be needed. How many of them could be built within the language as new objects and control structures? Thanks Dave > In addition, I have been considering using SELF as the main programming > language for a transactional based persistent distributed object store which I > have been working on for some time. SELF appears to offer an efficient > type of language which makes its choice as a standard language attractive. > However, its lack of key features, such as transaction control, locking, > distribution, and persistence, means that I will have to fudge the language > semantics. Mind you, considering the complexity of SELF, the first version > of this is liable to be a cut-down version of the language (microSELF?). > Maybe I could use uPSELF (persistent)? In fact, I will go and write that one > down :-). > > I have to agree that the other languages I have looked at (C/C++, Ada, etc) > would require similar semantic distortions to allow programming of my > store, but SELF has the advantage of being clean, new, and object-oriented > (truelly). Tasking would be nice though.... > > Gordon >

1 0

Re: Persistence and Transactions
by keith＠Uniteq.COM 01 Sep '92

01 Sep '92

> From Eng.Sun.COM!David.Ungar(a)netcomsv.netcom.com Fri Aug 28 11:42:19 1992 > Date: Fri, 28 Aug 92 11:16:14 PDT > From: Eng.Sun.COM!David.Ungar(a)netcomsv.netcom.com (Dave Ungar) > To: self-interest(a)self.stanford.edu, keith(a)Uniteq.COM > Subject: Re: Persistence and Transactions > Content-Length: 456 > > Nothing concrete, I'm afraid. We mull it over from time to time. > Why? > > Dave > > > > > Are there plans for providing object persistence and transactions? > > Snapshots are very limited in that the entire environment is saved. > > In order to be able to provide applications that have saveable state, > > are reliable, and that support multiple-user sharing of objects, persistence > > and transaction management should be an integral part of the Self environment. > > > > > Our company is doing object persistence and transactions for our system and I thought it would be nice to have a language that supports it more directly than the kludge-arounds that have to be done for C/C++.

2 1

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 September 1992