DOCSLIB.ORG

Actor Model of Computation

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Actor Model of Computation Published in ArXiv http://arxiv.org/abs/1008.1459 Actor Model of Computation Carl Hewitt http://carlhewitt.info This paper is dedicated to Alonzo Church and Dana Scott. The Actor model is a mathematical theory that treats “Actors” as the universal primitives of concurrent digital computation. The model has been used both as a framework for a theoretical understanding of concurrency, and as the theoretical basis for several practical implementations of concurrent systems. Unlike previous models of computation, the Actor model was inspired by physical laws. It was also influenced by the programming languages Lisp, Simula 67 and Smalltalk-72, as well as ideas for Petri Nets, capability-based systems and packet switching. The advent of massive concurrency through client- cloud computing and many-core computer architectures has galvanized interest in the Actor model. An Actor is a computational entity that, in response to a message it receives, can concurrently: send a finite number of messages to other Actors; create a finite number of new Actors; designate the behavior to be used for the next message it receives. There is no assumed order to the above actions and they could be carried out concurrently. In addition two messages sent concurrently can arrive in either order. Decoupling the sender from communications sent was a fundamental advance of the Actor model enabling asynchronous communication and control structures as patterns of passing messages. November 7, 2010 Page 1 of 25 Contents Introduction ............................................................ 3 Fundamental concepts ............................................ 3 Illustrations ............................................................ 3 Modularity thru Direct communication and asynchrony ............................................................. 3 Indeterminacy and Quasi-commutativity ............... 4 Locality and Security ............................................. 4 Computational Representation Theorem ............... 4 TM TM iAdaptive concurrency using ActorScript ...... 5 Other models of message-passing concurrency ..... 5 Historical Background ........................................... 5 Concurrency versus Turing‟s Model .................. 5 λ-Calculus .......................................................... 6 Petri nets ............................................................. 6 Simula ................................................................ 6 Planner................................................................ 7 Smalltalk-72 ....................................................... 7 Concurrency ....................................................... 8 Actors ................................................................. 8 Actor Semantics ................................................. 9 Logic Programming ......................................... 10 Reasoning about Actors ................................... 10 Early Actor Programming languages ............... 10 Causal Consistency .......................................... 10 Extension versus Specialization ....................... 12 Early Actor Programming languages ............... 12 Language constructs versus Library APIs ........ 13 Hairy Control Structure Redux ........................ 13 Promises ........................................................... 14 Garbage Collection ........................................... 14 Cosmic Cube .................................................... 14 J–Machine ........................................................ 15 π-Calculus ........................................................ 15 Was the Actor model premature? ..................... 15 Acknowledgment ................................................. 16 Bibliography ........................................................ 16 End Notes ............................................................. 21 November 7, 2010 Page 2 of 25 i Introduction Illustrations The Actor model is a mathematical theory of computation The Actor model can be used as a framework for that treats “Actors” as the universal primitives of modeling, understanding, and reasoning about, a wide concurrent digital computation [Hewitt, Bishop, and range of concurrent systems. For example: Steiger 1973; Hewitt 1977]. The model been used both as a Electronic mail (e-mail) can be modeled as an framework for a theoretical understanding of concurrency, Actor system. Accounts are modeled as Actors and as the theoretical basis for several practical and email addresses as Actor addresses. implementations of concurrent systems. Web Services can be modeled with SOAP endpoints modeled as Actor addresses. Unlike previous models of computation, the Actor model Objects with locks (e.g. as in Java and C#) can be was inspired by physical laws. It was also influenced by modeled as Actors. the programming languages Lisp [McCarthy et. al. 1962], Simula 67 [Dahl and Nygaard 1967] and Smalltalk-72 [Kay 1975], as well as ideas for Petri Nets [Petri 1962], Modularity thru Direct communication and capability-based systems [Dennis and van Horn 1966] and asynchrony packet switching [Baran 1964]. The advent of massive concurrency through client-cloud computing and many- Modularity in the Actor model comes from one-way asynchronous communication. Once a message has been core computer architectures has galvanized interest in the ii Actor model [Hewitt 2009b]. sent, it is the responsibility of the receiver. Messages in the Actor model are decoupled from the Fundamental concepts sender and are delivered by the system on a best efforts basis. This was a sharp break with previous approaches to An Actor is a computational entity that, in response to a models of concurrent computation in which message message it receives, can concurrently: sending is tightly coupled with the sender and sending a send a finite number of messages to other Actors; message synchronously transfers it someplace, e.g., to a create a finite number of new Actors; buffer, queue, mailbox, channel, broker, server, etc. or to designate the behavior to be used for the next the “ether” or “environment” where it temporarily resides. message it receives. The lack of synchronicity caused a great deal of misunderstanding at the time of the development of the There is no assumed order to the above actions and they Actor model and is still a controversial issue. could be carried out concurrently. In addition two messages sent concurrently can arrive in either order. Because message passing is taken as fundamental in the Actor model, there cannot be any inherent overhead, e.g., Decoupling the sender from communications sent was a any requirement for buffers, pipes, queues, classes, fundamental advance of the Actor model enabling channels, etc. Prior to the Actor model, concurrency was asynchronous communication and control structures as defined in low level machine terms. patterns of passing messages [Hewitt 1977]. It certainly is the case that implementations of the Actor model typically make use of these hardware capabilities. An Actor can only communicate with Actors to which it is However, there is no reason that the model could not be connected. It can directly obtain information only from implemented directly in hardware without exposing any other Actors to which it is directly connected. Connections hardware threads, locks, queues, channels, tasks, etc. Also, can be implemented in a variety of ways: there is no necessary relationship between the number of direct physical attachment Actors and the number threads, locks, tasks, queues, etc. memory or disk addresses that might be in use. Implementations of the Actor model network addresses are free to make use of threads, locks, tasks, queues, global email addresses assignment, coherent memory, transactional memory, cores, etc. in any way that is compatible with the laws for The Actor model is characterized by inherent concurrency Actors [Baker and Hewitt 1977]. of computation within and among Actors, dynamic creation of Actors, inclusion of Actor addresses in As opposed to the previous approach based on composing messages, and interaction only through direct sequential processes, the Actor model was developed as an asynchronous message passing with no restriction on inherently concurrent model. In the Actor model sequential message arrival order. November 7, 2010 Page 3 of 25 ordering is a special case that derived from concurrent The security of Actors can be protected in the following computation. ways: hardwiring in which Actors are physically A natural development of the Actor model was to allow connected Actor addresses in messages. A computation might need to tagged memory as in Lisp machines, etc. send a message to a recipient from which it would later virtual machines as in Java virtual machine, receive a response. The way to do this is to send a Common Language Runtime, etc. communication which has the message along with the signing and/or encryption of Actors and their address of another Actor called the customer along with addresses the message. The recipient could then cause a response message to be sent to the customer. A delicate point in the Actor model is the ability to synthesize the address of an Actor. In some cases security Of course, any Actor could be used as a customer to can be used to prevent the synthesis of addresses. receive a response message. By using customers, common However, if an Actor address is simply a bit string then control structures such a recursion, co-routines,
Load more

Recommended publications
  • Computer in French
    Volunteer Information Exchange Sharing what we know with those we know Volume 5 Number 8 September 11, 2015 Contribute To The VIE Links You Might Enjoy Long before the Neiman-Marcus “Kitchen Computer” and before any recipes on your PC, there was ECHO • Creation of Evans and Sutherland IV, a one-off home computer. Dave Cortesi writes a • 10 Pictures of PCs in schools in the 80's wonderful article describing this one-of-a-kind artifact. • Computer Art in 1969 Bill Worthington writes of his opportunity to visit the University of Manchester and the reconstructed • In Memoriam: Karl Taub, who started the Computer “Baby.” And he took some excellent pictures for us. Science departments at Carnagie Mellon and Columbia Universities in the 70's. Thanks once more to Chris Garcia for telling us about three recent acquisitions. • Ed Thelen sends along this link about the Librascope LGP-30. As always, send us your stories, anecdotes and adventures in computing. • Kate McGregor sent this link about the several Jim Strickland [email protected] archiving activities at Cisco iwhich the CHM is leading. • Happy 17 th birthday, Google—Sept 4 CHM Blog Ken Shirriff has written several excellent and detailed Recent CHM Blog Entries articles recently about the innards of the 1401. Kirsten Tashev keeps us up-to-date on new CHM blog • 1402 Operations entries. • Details on 1401 Qui-Binary arithmetic • Guest blogger, Adam Spring writes on Amiga • 1403 Print mechanism – explanation and animation Computing. The Amiga computer celebrated its 30th birthday at CHM this July. • 1401 Core Memory Operation Peter Hart will speak on “Making Shakey, the World's Docent Training: Women In Computing First Intelligent Robot on September 14.
    [Show full text]
  • A Universal Modular ACTOR Formalism for Artificial
    Artificial Intelligence A Universal Modular ACTOR Formalism for Artificial Intelligence Carl Hewitt Peter Bishop Richard Steiger Abstract This paper proposes a modular ACTOR architecture and definitional method for artificial intelligence that is conceptually based on a single kind of object: actors [or, if you will, virtual processors, activation frames, or streams]. The formalism makes no presuppositions about the representation of primitive data structures and control structures. Such structures can be programmed, micro-coded, or hard wired 1n a uniform modular fashion. In fact it is impossible to determine whether a given object is "really" represented as a list, a vector, a hash table, a function, or a process. The architecture will efficiently run the coming generation of PLANNER-like artificial intelligence languages including those requiring a high degree of parallelism. The efficiency is gained without loss of programming generality because it only makes certain actors more efficient; it does not change their behavioral characteristics. The architecture is general with respect to control structure and does not have or need goto, interrupt, or semaphore primitives. The formalism achieves the goals that the disallowed constructs are intended to achieve by other more structured methods. PLANNER Progress "Programs should not only work, but they should appear to work as well." PDP-1X Dogma The PLANNER project is continuing research in natural and effective means for embedding knowledge in procedures. In the course of this work we have succeeded in unifying the formalism around one fundamental concept: the ACTOR. Intuitively, an ACTOR is an active agent which plays a role on cue according to a script" we" use the ACTOR metaphor to emphasize the inseparability of control and data flow in our model.
    [Show full text]
  • The Future: the Story of Squeak, a Practical Smalltalk Written in Itself
    Back to the future: the story of Squeak, a practical Smalltalk written in itself Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay [Also published in OOPSLA ’97: Proc. of the 12th ACM SIGPLAN Conference on Object-oriented Programming, 1997, pp. 318-326.] VPRI Technical Report TR-1997-001 Viewpoints Research Institute, 1209 Grand Central Avenue, Glendale, CA 91201 t: (818) 332-3001 f: (818) 244-9761 Back to the Future The Story of Squeak, A Practical Smalltalk Written in Itself by Dan Ingalls Ted Kaehler John Maloney Scott Wallace Alan Kay at Apple Computer while doing this work, now at Walt Disney Imagineering 1401 Flower Street P.O. Box 25020 Glendale, CA 91221 [email protected] Abstract Squeak is an open, highly-portable Smalltalk implementation whose virtual machine is written entirely in Smalltalk, making it easy to debug, analyze, and change. To achieve practical performance, a translator produces an equivalent C program whose performance is comparable to commercial Smalltalks. Other noteworthy aspects of Squeak include: a compact object format that typically requires only a single word of overhead per object; a simple yet efficient incremental garbage collector for 32-bit direct pointers; efficient bulk- mutation of objects; extensions of BitBlt to handle color of any depth and anti-aliased image rotation and scaling; and real-time sound and music synthesis written entirely in Smalltalk. Overview Squeak is a modern implementation of Smalltalk-80 that is available for free via the Internet, at http://www.research.apple.com/research/proj/learning_concepts/squeak/ and other sites. It includes platform-independent support for color, sound, and image processing.
    [Show full text]
  • CS 2210: Theory of Computation
    CS 2210: Theory of Computation Spring, 2019 Administrative Information • Background survey • Textbook: E. Rich, Automata, Computability, and Complexity: Theory and Applications, Prentice-Hall, 2008. • Book website: http://www.cs.utexas.edu/~ear/cs341/automatabook/ • My Office Hours: – Monday, 6:00-8:00pm, Searles 224 – Tuesday, 1:00-2:30pm, Searles 222 • TAs – Anjulee Bhalla: Hours TBA, Searles 224 – Ryan St. Pierre, Hours TBA, Searles 224 What you can expect from the course • How to do proofs • Models of computation • What’s the difference between computability and complexity? • What’s the Halting Problem? • What are P and NP? • Why do we care whether P = NP? • What are NP-complete problems? • Where does this make a difference outside of this class? • How to work the answers to these questions into the conversation at a cocktail party… What I will expect from you • Problem Sets (25%): – Goal: Problems given on Mondays and Wednesdays – Due the next Monday – Graded by following Monday – A learning tool, not a testing tool – Collaboration encouraged; more on this in next slide • Quizzes (15%) • Exams (2 non-cumulative, 30% each): – Closed book, closed notes, but… – Can bring in 8.5 x 11 page with notes on both sides • Class participation: Tiebreaker Other Important Things • Go to the TA hours • Study and work on problem sets in groups • Collaboration Issues: – Level 0 (In-Class Problems) • No restrictions – Level 1 (Homework Problems) • Verbal collaboration • But, individual write-ups – Level 2 (not used in this course) • Discussion with TAs only – Level 3 (Exams) • Professor clarifications only Right now… • What does it mean to study the “theory” of something? • Experience with theory in other disciplines? • Relationship to practice? – “In theory, theory and practice are the same.
    [Show full text]
  • April 22 -- STEPS NSF 2012 Report
    ! 2012 REPORT ! STEPS Toward Expressive Programming Systems ! “A#Science#Experiment”# ! by# (In#random#order)#Yoshiki#Ohshima,#Dan#Amelang,#Ted#Kaehler,#Bert#Freudenberg,# Aran#Lunzer,#Alan#Kay,#Ian#Piumarta,#Takashi#Yamamiya,#Alan#Borning,#Hesam# Samimi,#Bret#Victor,#Kim#Rose*# VIEWPOINTS#RESEARCH#INSTITUTE# # # *These#are#the#STEPS#researchers#for#the#year#2012.#For#a#complete#listing# of#the#participants#over#the#length#of#the#project#see#the#section#on#the# NSF#site#which#contains#this#report.# TABLE OF CONTENTS — The STEPS Project for the General Public Summary of the STEPS project . Origin . STEPS aims at personal computing . What does STEPS look like? . STEPS is a “science project” . General approach . “T-shirt programming” . Overall map of STEPS . General STEPS results . Making “runnable maths” . Assessing STEPS Summary of STEPS research in 2012 . Inventing & building a language for STEPS “UI and applications”, and rewriting Frank in it . Producing a workable “chain of meaning” that extends from the screen all the way to the CPU . Inventing methods that create automatic visualizers for languages created from metalanguages . Continuing the start of “What vs How” programming via “Cooperating Languages and Solvers” Reflections on the STEPS Project to Date References Outreach Activities for final year of NSF part of the STEPS project Publications for the NSF part of the STEPS project Appendix I: KScript and KSWorld Appendix II: Making Applications in KSWorld ——— ! The$STEPS$Project$For$The$General$Public$ If#computing#is#important—for#daily#life,#learning,#business,#national#defense,#jobs,#and#
    [Show full text]
  • The Problem with Threads
    The Problem with Threads Edward A. Lee Electrical Engineering and Computer Sciences University of California at Berkeley Technical Report No. UCB/EECS-2006-1 http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html January 10, 2006 Copyright © 2006, by the author(s). All rights reserved. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. Acknowledgement This work was supported in part by the Center for Hybrid and Embedded Software Systems (CHESS) at UC Berkeley, which receives support from the National Science Foundation (NSF award No. CCR-0225610), the State of California Micro Program, and the following companies: Agilent, DGIST, General Motors, Hewlett Packard, Infineon, Microsoft, and Toyota. The Problem with Threads Edward A. Lee Professor, Chair of EE, Associate Chair of EECS EECS Department University of California at Berkeley Berkeley, CA 94720, U.S.A. [email protected] January 10, 2006 Abstract Threads are a seemingly straightforward adaptation of the dominant sequential model of computation to concurrent systems. Languages require little or no syntactic changes to sup- port threads, and operating systems and architectures have evolved to efficiently support them. Many technologists are pushing for increased use of multithreading in software in order to take advantage of the predicted increases in parallelism in computer architectures.
    [Show full text]
  • Edsger W. Dijkstra: a Commemoration
    Edsger W. Dijkstra: a Commemoration Krzysztof R. Apt1 and Tony Hoare2 (editors) 1 CWI, Amsterdam, The Netherlands and MIMUW, University of Warsaw, Poland 2 Department of Computer Science and Technology, University of Cambridge and Microsoft Research Ltd, Cambridge, UK Abstract This article is a multiauthored portrait of Edsger Wybe Dijkstra that consists of testimo- nials written by several friends, colleagues, and students of his. It provides unique insights into his personality, working style and habits, and his influence on other computer scientists, as a researcher, teacher, and mentor. Contents Preface 3 Tony Hoare 4 Donald Knuth 9 Christian Lengauer 11 K. Mani Chandy 13 Eric C.R. Hehner 15 Mark Scheevel 17 Krzysztof R. Apt 18 arXiv:2104.03392v1 [cs.GL] 7 Apr 2021 Niklaus Wirth 20 Lex Bijlsma 23 Manfred Broy 24 David Gries 26 Ted Herman 28 Alain J. Martin 29 J Strother Moore 31 Vladimir Lifschitz 33 Wim H. Hesselink 34 1 Hamilton Richards 36 Ken Calvert 38 David Naumann 40 David Turner 42 J.R. Rao 44 Jayadev Misra 47 Rajeev Joshi 50 Maarten van Emden 52 Two Tuesday Afternoon Clubs 54 2 Preface Edsger Dijkstra was perhaps the best known, and certainly the most discussed, computer scientist of the seventies and eighties. We both knew Dijkstra |though each of us in different ways| and we both were aware that his influence on computer science was not limited to his pioneering software projects and research articles. He interacted with his colleagues by way of numerous discussions, extensive letter correspondence, and hundreds of so-called EWD reports that he used to send to a select group of researchers.
    [Show full text]
  • An Algebraic Theory of Actors and Its Application to a Simple Object-Based Language
    An Algebraic Theory of Actors and Its Application to a Simple Object-Based Language Gul Agha and Prasanna Thati University of Illinois at Urbana-Champaign, USA {agha,thati}@cs.uiuc.edu http://osl.cs.uiuc.edu/ 1 Introduction The development of Simula by Ole-Johan Dahl and Kristen Nygaard introduced a number of important programming language concepts – object which supports modularity in programming through encapsulation of data and procedures, the concept of class which organizes behavior and supports Abstract Data Types, and the concept inheritance which provides subtyping relations and reuse [6]. Peter Wegner terms programming languages which use objects as object-based languages, and reserves the term object-oriented languages for languages which also support classes and inheritance [58]. Concurrency provides a natural model for the execution of objects: in fact, Simula uses co-routines to simulate a simple form of concurrency in a sequen- tial execution environment. The resulting execution is tightly synchronized and, while this execution model is appropriate for simulations which use a global virtual clock, it is not an adequate model for distributed systems. The Actor Model unifies the notion of objects with concurrency; an actor is a concurrent object which operates asynchronously and interacts with other actors by sending asynchronous messages [2]. Many models for concurrent and distributed computation have been devel- oped. An early and influential model is Petri Nets developed by Carl Adam Petri [44]. In the Petri Net model, there are two kinds of elements – nodes and tokens. Nodes are connected to other nodes by fixed (static) links. Tokens are passed be- tween nodes using these links.
    [Show full text]
  • Incorparating the Actor Model Into SCIVE on an Abstract Semantic Level
    Incorparating the Actor Model into SCIVE on an Abstract Semantic Level Christian Frohlich¨ ∗ Marc E. Latoschik† AI and VR Group, Bielefeld University AI and VR Group, Bielefeld University. ABSTRACT Since visual perception is very important for generating immer- sive environments, most VR applications focus on the graphical This paper illustrates the temporal synchronization and process flow simulation output. Tools like OpenGL Performer, Open Inven- facilities of a real-time simulation system which is based on the ac- tor [12], Open Scene Graph, OpenSG [11] or the VRML successor tor model. The requirements of such systems are compared against X3D [8] are based upon a hierarchical scene graph structure, which the actor model’s basic features and structures. The paper describes allows for complex rendering tasks. Extension mechanisms like how a modular architecture benefits from the actor model on the field routing or rapid prototyping via scipting interfaces allow for module level and points out how the actor model enhances paral- new customized node types and interconnected application graphs. lelism and concurrency even down to the entity level. The actor idea is incorporated into a novel simulation core for intelligent vir- Purpose-built VR application frameworks adopt and extend these mechanisms, by adding in- and output customization, see e.g. tual environments (SCIVE). SCIVE supports well-known and es- TM tablished Virtual Reality paradigms like the scene graph metaphor, Lightning [4], Avango [13], VR Juggler [3] or the CAVELib . field routing concepts etc. In addition, SCIVE provides an explicit Also network distribution paradigms are often integrated to enable semantic representation of its internals as well as of the specific distributed rendering on a cluster architecture, as can be seen in virtual environments’ contents.
    [Show full text]
  • Texts in Computer Science
    Texts in Computer Science Editors David Gries Fred B. Schneider For other titles published in this series, go to www.springer.com/series/3191 A.W. Roscoe Understanding Concurrent Systems Prof. A.W. Roscoe Oxford University Computing Laboratory Wolfson Bldg., Parks Road Oxford OX1 3QD UK [email protected] Series Editors David Gries Fred B. Schneider Department of Computer Science Department of Computer Science Upson Hall Upson Hall Cornell University Cornell University Ithaca, NY 14853-7501, USA Ithaca, NY 14853-7501, USA ISSN 1868-0941 e-ISSN 1868-095X ISBN 978-1-84882-257-3 e-ISBN 978-1-84882-258-0 DOI 10.1007/978-1-84882-258-0 Springer London Dordrecht Heidelberg New York British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library Library of Congress Control Number: 2010936468 © Springer-Verlag London Limited 2010 Apart from any fair dealing for the purposes of research or private study, or criticism or review, as per- mitted under the Copyright, Designs and Patents Act 1988, this publication may only be reproduced, stored or transmitted, in any form or by any means, with the prior permission in writing of the publish- ers, or in the case of reprographic reproduction in accordance with the terms of licenses issued by the Copyright Licensing Agency. Enquiries concerning reproduction outside those terms should be sent to the publishers. The use of registered names, trademarks, etc., in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant laws and regulations and therefore free for general use.
    [Show full text]
  • Fiendish Designs
    Fiendish Designs A Software Engineering Odyssey © Tim Denvir 2011 1 Preface These are notes, incomplete but extensive, for a book which I hope will give a personal view of the first forty years or so of Software Engineering. Whether the book will ever see the light of day, I am not sure. These notes have come, I realise, to be a memoir of my working life in SE. I want to capture not only the evolution of the technical discipline which is software engineering, but also the climate of social practice in the industry, which has changed hugely over time. To what extent, if at all, others will find this interesting, I have very little idea. I mention other, real people by name here and there. If anyone prefers me not to refer to them, or wishes to offer corrections on any item, they can email me (see Contact on Home Page). Introduction Everybody today encounters computers. There are computers inside petrol pumps, in cash tills, behind the dashboard instruments in modern cars, and in libraries, doctors’ surgeries and beside the dentist’s chair. A large proportion of people have personal computers in their homes and may use them at work, without having to be specialists in computing. Most people have at least some idea that computers contain software, lists of instructions which drive the computer and enable it to perform different tasks. The term “software engineering” wasn’t coined until 1968, at a NATO-funded conference, but the activity that it stands for had been carried out for at least ten years before that.
    [Show full text]
  • Actorscript™ Extension of C#®, Java®, Objective C®, Javascript ®, and Systemverilog Using Iadaptivetm Concurrency for Anti
    ActorScript™ extension of C#®, Java®, Objective C®, JavaScript®, and SystemVerilog using iAdaptiveTM concurrency for antiCloudTM privacy and security Carl Hewitt This article is dedicated to Ole-Johan Dahl and Kristen Nygaard. Message passing using types is the foundation of system communication: Messages are the unit of communication Types enable secure communication Actors ActorScript™ is a general purpose programming language for implementing iAdaptiveTM concurrency that manages resources and demand. It is differentiated from previous languages by the following: Universality o Ability to directly specify exactly what Actors can and cannot do o Everything is accomplished with message passing using types including the very definition of ActorScript itself. Messages can be directly communicated without requiring indirection through brokers, channels, class hierarchies, mailboxes, pipes, ports, queues etc. Programs do not expose low-level implementation mechanisms such as threads, tasks, locks, cores, etc. Application binary interfaces are afforded so that no program symbol need be looked up at runtime. Functional, Imperative, Logic, and Concurrent programs are integrated. A type in ActorScript is an interface that does not name its implementations (contra to object-oriented programming languages beginning with Simula that name implementations called “classes” that are types). ActorScript can send a message to any Actor for which it has an (imported) type. 1 o Concurrency can be dynamically adapted to resources available and current load. Safety, security and readability o Programs are extension invariant, i.e., extending a program does not change the meaning of the program that is extended. o Applications cannot directly harm each other. o Variable races are eliminated while allowing flexible concurrency.
    [Show full text]