Self-interest October 1993

self-interest@lists.selflanguage.org

13 participants
19 discussions

X and SELF
by ernst＠tivsu1.etec.uni-karlsruhe.de 26 Oct '93

26 Oct '93

Two questions: Has anyone 'out there' written an interface from SELF to Interviews? And Has anyone written an interface to any other user interface toolkit like Motif or Athena Widgets or so? Johannes Ernst ernst(a)itiv.etec.uni-karlsruhe.de Unversity of Karlsruhe, Germany

1 0

Announcing Self 3.0 Beta Release
by Lars.Bak＠Eng.Sun.COM 26 Oct '93

26 Oct '93

Announcing Self 3.0 Beta Release The Self Group at Sun Microsystems Laboratories, Inc., and Stanford University is pleased to announce the 3.0 Beta release of the experimental object-oriented exploratory programming language Self. Designed for expressive power and malleability, Self combines a pure, prototype-based object model with uniform access to state and behavior. Unlike other languages, Self allows objects to inherit state and to change their patterns of inheritance dynamically. Self's customizing compiler can generate very efficient code compared to other dynamically-typed object-oriented languages. Below is a list of changes and enhancements that have been made since the last release (2.0.1). Only the major changes are included. Language Changes: o Privacy is not enforced, although the privacy syntax is still accepted. The previous scheme was at once too restrictive (in that there was no notion of "friend" objects) and too lax (too many object had access to a private slot). We plan to include a better scheme in a future release. o Prioritized inheritance has been removed; the programmer must now manually resolve conflicts. We found the priority mechanism of limited use, and had the potential for obscure errors. System Changes: o The graphical browser has been extended to include editing capabilities. All programming tasks may now be performed through the graphical user interface (the "ui"). Type-ins allow for expression evaluation, menus support slot editing, and methods can be entered and edited. If you are familiar with a previous version of the SELF system, Section 14.1 of the manual entitled "How to Use SELF 3.0" contains a quick introduction to the graphical user interface. The impatient might want to read that first. o A mechanism - the transporter - has been added to allow arbitrary object graphs to be saved into files as SELF source. The system has been completely modularized to use the transporter; every item of source now resides in a transporter-generated module. Transporter-generated files have the suffix .sm to distinguish them from "handwritten" files (.self), though this may change as we move away from handwritten source. (Also, the transporter itself is likely to change in future releases.) o Every slot or object may now have an annotation (for example, to describe the purpose of the slot). In the current system, annotations are strings used to categorize slots. We no longer categorize slots using explicit category parent objects. Extra syntax is provided to annotate objects and slots. o A new profiler has been added, which can properly account for the time spent in different processes and the run-time system, and which presents a source-level profile including type information (i.e., methods inherited by different objects are not amalgamated in the profile, nor are calls to the same method from different sites). It also presents a consistent source-level view, abstracting from the various compiler optimizations (such as inlining) that may confuse the programmer. o The "new" compiler has been supplanted by the SIC ("simple inlining compiler"), and the standard configuration of the system is to compile first with the NIC ("non-inlining compiler") and recompile later with the SIC. Pauses due to compilation or recompilation are much smaller. o Characters are now single-byte strings. There is no separate character traits. SELF currently runs on SPARC-based Sun workstations using SunOS 4.1.x or Solaris 2.3. Self in NOT supported on Solaris prior to 2.3 due to an error in the OS interrupt handling. However, you may succeed on Solaris 2.2 by setting SICDeferUncommonBranch to false ("_SICDeferUncommonBranch: false") but no guarantees! The Sun-3 implementation is no longer supported. This release is available free of charge and can be obtained via anonymous ftp from self.stanford.edu. Also available for ftp are a number of papers published about Self. There is a mail group for those interested in random ramblings about Self, self-interest(a)self.stanford.edu. Send mail to self-request(a)self.stanford.edu to be added to it (please do not send such requests to the mailing list itself!). The Self Group at Sun Microsystems Laboratories, Inc. and Stanford University

2 1

Re: categorizing traits objects
by R James Noble 15 Oct '93

15 Oct '93

I've recently caught up with current batch of messages on the list (insert generic wry graduate-student-writing-thesis comment :-) so here are some belated comments about multiple inheritance and privacy. In general, I like the move towards a smaller language, and certainly the current inheritance and privacy facilities of Self are not particularly simple. But I think the information hiding and encapsulation of objects is an important part of the OO approach, and hope that Self's facilities in these areas will continue to evolve. Urs> Privacy ... a kind of stylized comment indicating your intention, So the syntax of privacy declarations are unchanged, privacy information is still available via mirrors, but slot privacy is ignored in program execution? Urs> In particular, privacy had no notion of "friend" - collaborating Urs> objects that have more access than the rest of the world but aren't Urs> related via inheritance. Yes. One idea I had was to extend the old scheme with "zero-priority parent" slots. They would act as other parent slots for the purposes of privacy checking (and directed resends) but would not be searched by the default lookup algorithm. This would provide the hole in the privacy algorithm, but without the problems of normal inheritance (even at low priority, unwanted messages can be inherited). I have used a programming device I've called "enemies" to much the same effect. For example, I say that example = (| ^ enemy = (| p* <- target. foo = (resend.foo). bar = (resend.bar). |). doFooToTarget = (enemy foo). |) makes object example an "enemy" of object target as far as messages foo and bar are concerned. This is much the same as target's members foo and bar being friends of example, but the link is the wrong way round. Therefore, where C++ has friends, Self has enemies. :-) John> Priorities... It is easy to write forwarding methods of the John> form: "foo = (parent1.foo)" to accomplish this I guess these methods could also be "handled automatically in the programming environment". Urs> Well, without parent priorities resend becomes very simple since Urs> it always searches upwards starting from the resending method Urs> holder. With the revision of inheritance and privacy, has the "delegated perform" been changed? The new privacy scheme should remove some problems --- currently, the lookup for the receiver's private methods starts in the delegatee, but the delegatee cannot necessarily access those slots. However, a "method holder" parameter is probably needed here, as mentioned in the code. This would be useful for my "encapsulators" for monitoring objects, but should be powerful enough to implement general per-object message dispatching, but without the necessity for a full meta-level. It should be quite possible to use this to simulate prioritised multiple inheritance at runtime, or even dynamically construct the above forwarding methods. James Noble kjx

1 0

Re: catagorizing traits objects
by jecel＠lsi.usp.br 12 Oct '93

12 Oct '93

> Wow, sounds neat! > > Please keep us posted. > > Thanks > > Dave Ungar I will certainly post here all the results I get as soon as I have any. This should be in a few weeks ( I've been saying that since January :). I do have some published papers on this, but it is all in Portuguese. Too bad I won't be able to share my implementation for more people to test as it runs on the Merlin IV computer and there is currently one of those ( I do my own hardware, assembler, etc. which does not help speed things up :< - at least I gave up designing my own processor :) ). After this is running on one machine, it should be easier to port to others via smalltalk-like cloning. I plan to have a reduced version of Self running on a 64 processor ( 68020 ) machine in the next few months - this is what the papers I mentioned are about. =================== /\/\ Merlin Computers Jecel Assumpcao Jr / /\ \ + LSI - Universidade de Sao Paulo jecel(a)lsi.usp.br '-/----\-' + Pontificia Universidade Catolica =================== '------' Sao Paulo - Brazil

1 0

Self & Threads
by alex＠XAIT.Xerox.COM 11 Oct '93

11 Oct '93

SelfMeisters, What about multi-threading in Self under Solaris 2.3? Has there been any thoughts about how threads might work in the Self model? Alexis Layton alex(a)XAIT.Xerox.COM

1 0

Further updates on Solaris 2.x availability
by Tim Hoffman SE - Western Australia 11 Oct '93

11 Oct '93

Hi I gather self for solaris 2.x is not all that far away, any updates on expected availability. Having shifted over to Solaris 2.x for at least a year, means I haven't been able to play with self in an awfully long time. Tim

2 1

Re: categorizing traits objects
by jecel＠lsi.usp.br 09 Oct '93

09 Oct '93

> > Ohhhh... NO!!! I think one of the major advantages of Self compared with > > Smalltalk is the possibillity to define private slots. Looking at Digitalk's > > Smalltalk/V you can find a lot of methods with comment "Private", even though > Privacy is a Good Thing, no doubt about that. However, we felt that > the current (2.0) privacy semantics didn't do the right thing. Often, > too many objects had access to "private" slots, and all-to-often we > annotated slots with "_", meaning "I consider it private but had to > make it public to allow access". In particular, privacy had no notion > of "friend" - collaborating objects that have more access than the > rest of the world but aren't related via inheritance. Back in 1984 I designed a privacy scheme for Smalltalk: every class had two method dictionaries - one which was searched for normal messages and another that was used for messages to self. The browser put public methods in both dictionaries but private methods only in the second ( you could even have methods that anybody but yourself could send! ). You can imagine that I was quite excited to see this feature in Self. In practice, though, I *never* got around to using it. So I am not sorry to see it go. Right now I am trying to make a "multiuser" Self. Each object would belong to a user and could only be modified by that user. Besides the "real" users there would be many pseudo users created just to break up the system into smaller ( somewhat protected ) modules. All objects from the same user would be "friends", but in my scheme every readable slot is free game for everybody. This obviously needs work. - Jecel

1 0

Re: categorizing traits objects
by jecel＠lsi.usp.br 09 Oct '93

09 Oct '93

John.Maloney(a)Eng.Sun.COM writes: > 1. Privacy is no longer supported by the VM. Thus, the slot found by > 2. All parents now have the same priority. This resulted in a vast This is what I like most about Self - you remove things in every release! All other languages get fatter and fatter each year. How about dumping the Virtual Machine in the next round? I'm serious. Keep up the good work! =================== /\/\ Merlin Computers Jecel Assumpcao Jr / /\ \ + LSI - Universidade de Sao Paulo jecel(a)lsi.usp.br '-/----\-' + Pontificia Universidade Catolica =================== '------' Sao Paulo - Brazil

1 0

Re: re: categorizing traits objects
by John.Maloney＠Eng.Sun.COM 08 Oct '93

08 Oct '93

Re: Are you still keeping traits objects separate from prototypes? Yes. -- John

1 0

correction
by John.Maloney＠Eng.Sun.COM 08 Oct '93

08 Oct '93

I meant to say "we have NOT encountered a situation..." in the second to last line of the following message. -- John ------- Forwarded Message To: mcr(a)ccs.carleton.ca (Michael Richardson) Cc: self-interest(a)self.stanford.edu, bjoern(a)ifki50.informatik.fh-muenchen.de, jmaloney Subject: Re: categorizing traits objects Date: Fri, 08 Oct 93 10:34:29 PDT From: jmaloney I think our experience suggests that even something that seems simple like "breadth first search" can sometimes result in unexpected behavior, especially for "resends". Furthermore, I believe it makes programs more readable to make the programmer's intent explicit when different methods for the same message are inherited via several parents. It is easy to write forwarding methods of the form "foo = (parent1.foo)" to accomplish this. So far, we have encountered a situation where more than a few such methods were required. -- John ------- End of Forwarded Message

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 October 1993