"Object Oriented Programming with Prototypes", Gunther Blaschek, Springer-Verlag, 1994, ISBN 3-540-56469-1 or ISBN 0-387-56469-1.
It is about the programming language Omega which is (was) a prototype-based language for Macintosh. It has a lot of mentions of Self and a few of the elusive language Kevo (if anyone has a copy of Kevo around, let me know!). The first third of the book is about OO and prototype-based languages. I never had a Mac, so it wasn't as useful as it could have been when I got it.
Best, Kyle
On Thursday 25 July 2002 12:24 pm, kyle_hayes@speakeasy.net wrote:
a few of the elusive language Kevo (if anyone has a copy of Kevo around, let me know!).
ftp://ftp.uni-koeln.de/usenet/comp.archives/auto/comp.lang.forth/Kevo.z
Here's what I found with a search (it's old, though):
author: Antero Taivalsaari tsaari@cs.uta.fi ftp://cs.uta.fi/pub/kevo/ kevo-interest@ursamajor.uvic.ca
The book "Object Oriented Languages" by Gerald Masini and others has a good discussion of different object models including prototypes.
Btw, Is there a strong distinction between prototypes and frames? The history of protos seems to be Actors -> Frames -> Prototypes.
Cheers, Steve
On Thursday 25 July 2002 17:47, Steve Dekorte wrote:
Btw, Is there a strong distinction between prototypes and frames?
Frames are pure data structures, not objects.
The history of protos seems to be Actors -> Frames -> Prototypes.
I am pretty sure that Frames were already being used in the late 1960s while Actors were inspired by Smalltalk-72. Actors were prototype based systems, but had monolithic "scripts" for behavior instead of a set of methods in slots. You might say that Frames + Actors => Self
-- Jecel
On Friday, July 26, 2002, at 11:35 AM, Jecel Assumpcao Jr wrote:
On Thursday 25 July 2002 17:47, Steve Dekorte wrote:
Btw, Is there a strong distinction between prototypes and frames?
Frames are pure data structures, not objects.
The history of protos seems to be Actors -> Frames -> Prototypes.
I am pretty sure that Frames were already being used in the late 1960s while Actors were inspired by Smalltalk-72. Actors were prototype based systems, but had monolithic "scripts" for behavior instead of a set of methods in slots. You might say that Frames + Actors => Self
I see. Also, I know the Self papers referenced some Smalltalk projects that used protos, but I checked those papers out and they reference Leiberman's papers on Actors. So maybe the geological record of protos looks like:
LISP and Simula --> Smalltalk and Frames --> Actors -> Smalltalk proto projects -> Self -> NewtonScript/JavaScript/Others
Steve
On Friday 26 July 2002 16:50, Steve Dekorte wrote:
LISP and Simula --> Smalltalk and Frames --> Actors -> Smalltalk proto projects -> Self -> NewtonScript/JavaScript/Others
That looks very reasonable.
And thanks, Albertina, for the detailed reference on the link between Actors (Plasma, in particular) and Smalltalk. Note that the Smalltalk described there (Smalltalk-72 as I had mentioned) was significantly different from Smalltalk-76 and later. It had a token stream message passing (mentioned in the text you cited) which was generalized as mail boxes in Actors. It had classes but these weren't objects (a limitation languages like C++ still have today). Each class had a single script instead of methods, just like Actors.
-- Jecel
On Friday, July 26, 2002, at 02:28 PM, Jecel Assumpcao Jr wrote:
Each class had a single script instead of methods, just like Actors.
Is it appropriate to call a language that has a "thread"-per-object execution model with each object containing a message queue an Actor-based language? Or does it have to also have other properties of the original Actor languages?
Steve
Jecel Assumpcao Jr wrote: Hi, Jecel:
On Thursday 25 July 2002 17:47, Steve Dekorte wrote:
Btw, Is there a strong distinction between prototypes and frames?
Frames are pure data structures, not objects.
The history of protos seems to be Actors -> Frames -> Prototypes.
I am pretty sure that Frames were already being used in the late 1960s while Actors were inspired by Smalltalk-72. Actors were prototype based systems, but had monolithic "scripts" for behavior instead of a set of methods in slots. You might say that Frames + Actors => Self
In the intriguing paper entitled "Towards a programming apprentice" by Carl E. Hewitt and Brian Smith you have the description of The Actor Model of Computation (published by IEEE Transactions on Software Engineering Vol. SE I, no.1, March 1975 p.26-45
There he describes the main influences on the development of the actor model of computation:
Kay proposed a language called SMALLTALK with a token stream oriented interpreter to implement these ideas on a small portable computer which he calls the DYNABOOK. Token stream interpreters similar in certain ways to SMALLTALK had been previously developed by P. Samson at MIT and V.Pratt at Stanford u. i iIn November 1972, P. Bishop and C. Hewitt were working to try to obtain a general solution to the control structure problems which had continued to plague PLANNER-like problem solving systems for some years.A problem with Sussman's "possibility lists" is that simply looking at their contents using try-next can cause unfortunate global side effects. These side effects which result merely from attempting to look at the possibilities, make CONNIVER programs hard to debug and understand. The token streams of SMALLTALK have the same side-effect problem as the possibility lists of CONNIVER.
By December 1972, we succeeded in generalizing the message mechanism of SMALLTALK and SIMULA-67; the port mechanism of Krutar, Balzer and Mitchell; and the previous call statement of PLANNER-71 to a universal communication mechanism. Our generalization solved the control structure problems that Hewitt pointed out to Kay in the design of Smalltalk. The actor transmission communication primitive was developed as part of a new language- independent, machine-independent, behavioral model of computation for actors. The development of the actor model of computation and its ramifications is our principal original contribution to this area of research. Although they bear a certain family resemblance, PLASMA and SMALLTALK are rather different systems. Many of the differences have come about because S. and P. were created to serve different purposes. We believe that SMALLTALK may be better suited than PLASMA for some of its applications and that conversely PLASMA has certain advantages for our applications. Difficult problems in system design come from attempting to rationalize the interaction of various capabilities. In our research program, the development of PLASMA is not an end in itself. It is only a convenient formalism for expressing semantic relationships which have an existence and importance that is completely independent of P. We feel that our research on actor semantics has a deeper and more fundamental character. Plasma is a system dedicated to the direct realization of this semantic base.
The following were the main influences on the development of the actor model of computation.
1) The suggestion by Kay that procedural embedding be extended to cover data structures in the context of our previous attempts to generalize the work by Church, Landin, Mitchell Krutar, Balzer, Reynolds, Bobrow-Wegbreit and Sussman. 2) The context of our previous attempts to clean up and generalize the work on co-routine control structures of Landin, Mitchell, Krutar, Balzer, Reynolds, BobrowWegbreit and Sussman. 3) The influence of S. Papert's little man metaphor for computation in LOGO> 4) The limaitations and complexities of capability-based protection schemes. Every actor transmission is in effect an interdomain call efficiently providing an intrinsic protection on actor machines. 5) The experience developing previous generations of PLANNER (particularly the constructor-decomposers of PLANNER-71). Essentially the whole PLanner-71 language was implemented by J. Davies in POP-2 at the University of Edinburgh.
Kay has been extremely helpful in discussionns both of overall philosophy and technical details. Most of the insights given below on the relationship between actors and SMALLTALK come as a direct result of Hewitt being able to visit Kay in August 1973 at the time of the IJCAI-73 to discuss the various issues with him and the members of this group!
Below we discuss a number of differences between PLasma and Smalltalk.
Pragmatically SMalltalk is designed to be alanguage easily usable by children of all ages whereas PLASMA is designed to be a transparent formalism for expressing actor computations. PLASMA is designed to be a system in which any effective actor system can be conveniently implemented. Our contribution in basing PLASMA on actor semantics from the very beginning introduced fundamental differences in content and outlook between our project and Kay's. Plasma is designed to be used by experienced programmers.
It also serves as the language for our programming apprentice which gives it a further bias toward exceptional cleanliness of behavioral definition of all language constructs. We have tried to design PLASMA so that as many properties as possible of the behavior of an actor implemented in the language should be manifest in the structure of the code. Programs in plasma have a uniform actor basis...Then he starts a very nice description of this actor basis.
I love History. I believe History triggers the unfolding of consciousness...All I care about...
BEst wishes Albertina
-- Jecel
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
========================================== This email message has been verified against viruses and SPAM using MIMESweeper. Este email foi verificado quanto a SPAM e virus utilizando MIMESweeper. http://www.mimesweeper.com ==========================================
Sorry that I send this huge files to the list. My intention was to send them to kyle_hayes@speakeasy.net.
Sorry again
On Saturday 27 July 2002 03:27, Thorsten Dittmar wrote:
Sorry that I send this huge files to the list.
Accidents happen, specially with the current "reply-to:" setting of this list (but the previous setting, where you have to reply-to-all for it to go to the list, also caused problems which is why it was changed).
I had also been very interested in seeing Kevo in action for many years. But the running system was rather weak compared to the outliners we have in Self. I found it a better learning experience to just look at the .kevo files with a text editor.
BTW, though I looked at this on a Mac, people on Linux can decompress the files with the MacUtils package. I don't know if WinZip handles .sit files.
-- Jecel
=========== Hi Selfers: Could someone arrange as a file the chapter about Classes vs. prototypes: some philosophical and historical observations In James Noble, Antero Taivalsaari and Ivan Moore eds. Prototype-based progamming:concepts, languages and applications chapter 1, Springer Verlag, 1999? Special thanks! Albertina
self-interest@lists.selflanguage.org
-
Albertina Lourenci -
Jecel Assumpcao Jr -
kyle_hayes＠speakeasy.net -
Ned Konz -
Steve Dekorte -
Thorsten Dittmar