<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
 
<p>Jecel Assumpcao Jr wrote:
<br>Hi, Jecel:
<blockquote TYPE=CITE>On Thursday 25 July 2002 17:47, Steve Dekorte wrote:
<br>> Btw, Is there a strong distinction between prototypes and frames?
<p>Frames are pure data structures, not objects.
<p>> The history of protos seems to be Actors -> Frames -> Prototypes.
<p>I am pretty sure that Frames were already being used in the late 1960s
<br>while Actors were inspired by Smalltalk-72. Actors were prototype based
<br>systems, but had monolithic "scripts" for behavior instead of a set
of
<br>methods in slots. You might say that Frames + Actors => Self
<br> </blockquote>
In the intriguing paper entitled "Towards a programming apprentice" by
<br>Carl E. Hewitt and Brian Smith you have the description of The Actor
<br>Model of Computation (published by IEEE Transactions on Software
<br>Engineering Vol. SE I, no.1, March 1975 p.26-45
<p>There he describes the main influences on the development of the actor
<br>model of computation:
<p>Kay proposed a language called SMALLTALK with a token stream oriented
<br>interpreter to implement these ideas on a small portable computer which
he
<br>calls the DYNABOOK. Token stream interpreters similar in certain ways
to
<br>SMALLTALK had been previously developed by P. Samson at MIT and
<br>V.Pratt at Stanford u.
<br>i
<br>iIn November 1972, P. Bishop and C. Hewitt were working to try to obtain
<br>a general solution to the control structure problems which had continued
to plague
<br>PLANNER-like problem solving systems for some years.A problem with
Sussman's
<br>"possibility lists" is that simply looking at their contents using
try-next can cause unfortunate
<br>global side effects. These side effects which result merely from attempting
to look at the
<br>possibilities, make CONNIVER programs hard to debug and understand.
<br>The token streams of SMALLTALK have the same side-effect problem as
the
<br>possibility lists of CONNIVER.
<p>By December 1972, we succeeded in generalizing the message mechanism
of SMALLTALK
<br>and SIMULA-67; the port mechanism of Krutar, Balzer and Mitchell; 
and the previous call
<br>statement of PLANNER-71 to a universal communication mechanism. Our
generalization solved
<br>the control structure problems that Hewitt pointed out to Kay in the
design of Smalltalk.
<br>The actor transmission communication primitive was developed as part
of a new language-
<br>independent, machine-independent, behavioral model of computation for
actors. The development
<br>of the actor model of computation and its ramifications is <font size=+2>our
principal original</font>
<br><font size=+2>contribution to this area of research.</font>
<br>Although they bear a certain family  resemblance, PLASMA and SMALLTALK
are rather
<br>different systems. Many of the differences have come about because
S. and P. were
<br>created to serve different purposes. We believe that SMALLTALK may
be better
<br>suited than PLASMA for some of its applications and that conversely
PLASMA has
<br>certain advantages for our applications.
<br>Difficult problems in system design come from attempting to rationalize
the interaction
<br>of various capabilities. In our research program, the development of
PLASMA is
<br>not an end in itself. It is only a convenient formalism for expressing
semantic relationships
<br>which have an existence and importance that is completely independent
of P.
<br>We feel that our research on actor semantics has a deeper and more
fundamental
<br>character. Plasma is a system dedicated to the direct realization of
this semantic base.
<p><font size=+2>The following were the main influences on the development</font>
<br><font size=+2>of the actor model of computation.</font><font size=+2></font>
<p>1) The suggestion by Kay that procedural embedding be extended to cover
data structures
<br>in the context of our previous attempts to generalize the work by Church,
Landin, Mitchell
<br>Krutar, Balzer, Reynolds, Bobrow-Wegbreit and Sussman.
<br>2) The context of our previous attempts to clean up and generalize
the work on co-routine
<br>control structures of Landin, Mitchell, Krutar, Balzer, Reynolds, BobrowWegbreit
<br>and Sussman.
<br>3) The influence of S. Papert's little man metaphor for computation
in LOGO>
<br>4) The limaitations and complexities of capability-based protection
schemes.  Every
<br>actor transmission is in effect an interdomain call efficiently providing
an intrinsic
<br>protection on actor machines.
<br>5) The experience developing previous generations of PLANNER (particularly
<br>the constructor-decomposers of PLANNER-71). Essentially the whole PLanner-71
<br>language was implemented by J. Davies in POP-2 at the University of
Edinburgh.
<p><font size=+2>Kay has been extremely helpful in discussionns both</font>
<br><font size=+2>of overall philosophy and technical details.</font>
<br>Most of the insights given below on the relationship between actors
and SMALLTALK
<br>come as a direct result of Hewitt being able to visit Kay in August
1973 at the
<br>time of the IJCAI-73 to discuss the various issues with him and the
members of this group!
<p>Below we discuss a number of differences between PLasma and Smalltalk.
<p><font size=+2>Pragmatically SMalltalk is designed to be alanguage</font>
<br><font size=+2>easily usable by <font color="#FF0000">children of all
ages </font>whereas </font> PLASMA<br>
is designed to be a transparent formalism for expressing actor computations.
PLASMA<br>
is designed to be  a system in which any effective actor system can
be conveniently
<br>implemented. Our contribution in basing PLASMA on actor semantics from
the
<br>very beginning introduced fundamental differences in content and outlook
between
<br>our project and Kay's. Plasma is designed to be used by experienced
programmers.
<p>It also serves as the language for our programming apprentice which
gives it a further
<br>bias toward exceptional cleanliness of behavioral definition of all
language constructs.
<br>We have tried to design PLASMA so that as many properties as possible
of the
<br>behavior of an actor implemented in the language should be manifest
in the
<br>structure of the code.
<br>Programs in plasma have a uniform actor basis...Then he starts a very
nice
<br>description of this actor basis.
<p>I love History. I believe History triggers the unfolding of consciousness...All
I
<br>care about...
<p>BEst wishes
<br>Albertina
<br> 
<br> 
<blockquote TYPE=CITE> 
<br>-- Jecel
<br> 
<br> 
<p>Your use of Yahoo! Groups is subject to <a href="http://docs.yahoo.com/info/terms/">http://docs.yahoo.com/info/terms/</a>
<p>==========================================
<br>This email message has been verified against viruses and SPAM using
MIMESweeper.
<br>Este email foi verificado quanto a SPAM e virus utilizando MIMESweeper.
<br><a href="http://www.mimesweeper.com">http://www.mimesweeper.com</a>
<br>==========================================</blockquote>
</html>