
Actalk info file:

	INFO


Purpose:
--------

This file provides minimal info on installation and use of Actalk testbed.


Warning:
--------

This file, and generally speaking Actalk documentation, is under progress.
This is still a partially incomplete version.


Installation:
-------------

After untaring the distribution (tar) file, you should have the following files
in your current directory:

	README			entry point info file,
	VERSION_3.*		info file about versions,
	INFO			info file about actual installation and use,
	Actalk-FileIn.st	the loading file,
	src/			directory containing source files.

First you have to edit the loading file named Actalk-FileIn.st.

Its first lines should look like:

-------------- start
"
Actalk loading file:

	Actalk-FileIn.st


The following temporary variable should be set
at the time of installing the Actalk system.
It must indicate the full path name of the directory/folder
where the Actalk sources (src) are located.
(Below are my own Macintosh and Unix paths as examples)."

| path |
	"Mac Finder:"
path := 'Macintosh HD:Programmation:Smalltalk-80:Actalk:3:src:'.
	"Unix:"
path := '/home/camille1/briot/smalltalk/actalk/3/src/'.

"A few little but useful extensions."
...
...
-------------- end

You have to rewrite the path name string according to current directory.
Notice that two examples of paths are proposed depending on whether you load
Actalk on a Macintosh or Unix workstation.
Put under comments or remove the path that which you possibly don't use.

Then you may launch Objectworks\Smalltalk release 4.1
(with or without VisualWorks).

Through a FileList tool, you may load file Actalk-FileIn.st.

This will load the entire Actalk system.

If everything works fine (it should!),
by opening a new browser or updating one,
you will find listed numerous new categories, all starting with Actalk.

You may then save an Actalk image
to avoid having to reload the source files next time.


Comments:
---------

Following information provides minimal insights into the objectives and
architecture of the Actalk testbed, as well as main advices for using it.
Most of information is currently located within the documentation of
the program itself. That is, every class is commented, as well as almost
every non trivial method.
So look for comments!


Architecture:
-------------

The Actalk platform may be decomposed into:

	the kernel classes which provide the kernel implementation
	and specification of standard active objects,

	and its libraries which implement various OOCP languages
	and constructs as well as related examples.


Kernel:
-------

The pair of kernel classes Actor and ActorBehavior model the notion of an
active object (that is which owns its activity) and which communicates with
other active objects through unidirectional asynchronous message passing
(that is with no reply and no waiting).
We call such active objects by the generic name of actors,
mainly because it is a shorter term!

Actalk is aimed at modeling various kind of actor and also called object-
oriented concurrent programming models and languages (that is various models
of object activity, message passing, synchronization...) as proposed by various
programming languages of that kind.
(See the book "OOCP", edited by Akinori Yonezawa and Mario Tokoro, MIT-Press,
1987, for an introduction. Actalk extensions implement many of the languages
models and constructs described within this book).

These simulations are implemented as subclasses of the two kernel classes.
Therefore Actalk provides a testbed environment where various OOCP programming
models and constructs are implemented and may be related, compared,
and possibly combined.


Libraries:
----------

The Actalk libraries are organized as Smalltalk-80 categories
(modules of classes).
Actalk libraries may be decomposed into:

	Actalk-Kernel-*		the kernel categories,
	Actalk-Examples		examples,
	Actalk-Ext-*		extensions to describe and implement
				various languages constructs,
	Actalk-Synchro-*	extensions specific to describe
				various models for synchronizing requests,

	*			remaining files are library facilities for
				kernel usage, support for examples,
				and environment facilities
				(e.g., time-slicing facility).


Environment Tools:
------------------

Customizing environment tools for actors (including an extended MVC framework
for actors and a generic time-slicing scheduler plus other tools) is another
dual project which has been achieved into previous version 2
(implemented by Loic Lescaudron in Smalltalk-80 release 2.5).
These tools should be eventually reintroduced within current Actalk version 3.


Objectives:
-----------

As for any system, Actalk represents a compromise between various goals and
constraints.

Minimality and simplicity.

We concentrate on modeling key aspects and constructs of various OOCP
languages. We therefore leave aside concerns in optimization (including
precompilation) and strong safety (performing lots of checking)
when it would greatly complexify implementation.

Integration.

Actalk is fully integrated within the Smalltalk-80 environment.
We don't change Smalltalk-80 syntax or semantics.
One may combine OOCP programs (active objects and asynchronous message
passing) with standard OOP programs (underlying Smalltalk-80).
One may also use powerful Smalltalk-80 programming environment tools
to develop and test constructs and programs.
(Note however that because of autonomous activity and asynchronous message
passing, tools like the MVC interface framework and the debugger do not work
exactly as usual. See section 'Warnings:' and info file VERSION_3.*).

Expressivity.

The kernel of Actalk has been carefully designed in order to
allow maximal expressivity (derivation of various models and constructs)
while being minimal.
A full reflective approach has not be chosen
in order to keep up with minimality and easy integration within
the underlying Smalltalk-80 system.
(Actually a reflective extension/version of Actalk, named ReActalk,
has been achieved by Sylvain Giroux at University de Montreal.)
The underlying Smalltalk-80 system may actually be considered
as a reasonable approximation of some meta-description of Actalk.
This is because Smalltalk is both: very high-level,
including reflective abilities, and object-oriented,
that is indeed very close to object-oriented concurrent programming.

Experiments.

Actalk offers a large amount of libraries modeling a wide variety
of OOCP models, constructs, and examples.
Because all these simulations are integrated within the same environment
and framework, they may be easily studied, compared, extended,
and even at some degree combined.
(Actually combining several libraries proves to be a non-trivial
issue because there could be some incompatibilities between them.
See the section 'Actor and ActorBehavior:').


Hybrid programming:
-------------------

Actalk is an example of a hybrid system.
That is standard sequential objects and message passing cohabit with active
objects (actors) and asynchronous message passing.
The programmer may set the granularity of its actors,
i.e., fine grained actors or/and large grained active objects.
In case of large grained objects, the programmer encapsulates a few activities
within a few actors. Each actor is then composed of several interacting standard
Smalltalk-80 objects.
Obviously any kind of granularity may be achieved by the designer.
The examples of category Actalk-Ext-Replace-Examples
(following the actor computation model)
show examples of fine grained actors.


Actor and ActorBehavior:
------------------------

The Actalk kernel is decomposed into two kernel classes:
class Actor and class ActorBehavior,
in order to provide maximum genericity.

Class Actor is the class which implements the external shell of an actor.
It acts mostly as a container for the mailbox which will contain incoming
messages and the behavior which will process them.

Class ActorBehavior implements the behavior of an actor.
It is the object which eventually consumes incoming messages and computes
them (serially).

The distinction between these two classes is useful.
For instance in some models with intra-object concurrency,
e.g. class ReplaceActorBehavior
(behavior replacement model of the actor computation model),
there could be several behaviors active within the same actor.
Meanwhile this decomposition of an actor into two component classes
imposes minimal consistency between classes of Actor kind and classes
of ActorBehavior kind. For instance subclasses IRActor and IRActorBehavior,
which implement implicit reply, should be paired, see class IRActorBehavior
comment.


Concurrency:
------------

Actors instances of kernel classes (let's say kernel actors)
compute messages serially.
This means that there is inter-object concurrency
(between various objects activities)
but no intra-object concurrency
(that is at most one activity within an active object).

Classes ReplaceActorBehavior and CountersActorBehavior are some examples
of intra-object concurrency.
Class SuspendActorBehavior is an example of intra-object quasi-concurrency
(that is there could be many activities within one object, but only one at a time
is actually active, the other ones being suspended onto conditions,
as for monitors).

For kernel actors, message passing is asynchronous and unidirectional.
This means that the sender does not wait for completion of the computation
of its request by the receiver and does not get a reply.
If a reply needs to be returned, it should be returned through another
independent message transmission.
(Default reply selector is by convention the selector reply:.
See next section 'Differences ...:',
as well as class BlockContinuation comment,
and examples in category Actalk-Examples.)

Classes like AbclActor, IRActor and others provide others types of
message passing and synchronization patterns,
like synchronous and also future type (with an eager reply).


Differences with standard Smalltalk programs:
---------------------------------------------

To define and use an Actalk actor,
there are four main differences compared with standard Smalltalk programming:

1)
The class defining behaviors should be defined as a subclass of class
ActorBehavior (or one of its subclasses) and not as a subclass of class Object.

(If we take the seminal example of a counter, see category Actalk-Examples)

	ActorBehavior subclass: #Counter
		instanceVariableNames: 'contents '
		classVariableNames: ''
		poolDictionaries: ''
		category: 'Actalk-Examples'

2)
When creating an instance, the message actor should be sent to the
new behavior in order to construct (and return) the final actor.

	Counter new actor.
	"or"
	(Counter new contents: 100) actor

3)
Because message passing is asynchronous, no implicit reply is returned
as a value of the message transmission.
If a reply is needed, one should explicitly program the reply message,
as well as conveying the reply destination within the initial message.

	consultAndReplyTo: r
		"Consult the contents and reply it to the reply destination."

		r reply: contents

See categories Actalk-Examples and Actalk-Kernel-JoinCont
for predefined reply destination behaviors.
(Note also that classes IRActor and IRActorBehavior provide implicit reply
as in standard Smalltalk-80. See their comments).

4)
The self reference of an actor is pseudo variable aself (and not self).
Seen from within (the context of) the behavior,
aself represents the actor of which it is a behavior, and
self represents the behavior itself.
By sending a message to aself, the actor behavior sends
(asynchronously through its mailbox) a message to itself (as an actor).
By sending a message to self, the actor behavior sends
(as in standard Smalltalk) a message directly to itself (behavior).


Hybrid programming methodology:
-------------------------------

In order to clearly distinguish within a behavior between:
standard Smalltalk methods (for instance to initialize instance variables),
and "actor" method selectors intended to be sent to the actor,
we take following convention.

We group "actor methods" within the category protocol named 'script'.
Script methods are intended to be requested through actor message passing.

Alternatively, when modeling medium grained or large grained actors,
inner computation is described as standard Smalltalk message passing
between the sub components of the behavior, being standard objects.
By convention such private inner computation methods are grouped within
the category protocol named 'private routines'.
(We actually follow ABCL/1 terminology and convention.)
Such standard Smalltalk-80 methods should only be requested
by the behavior itself (by sending a message to self).


Generic events methods:
-----------------------

Actalk includes generic event handling methods
(three of them: associated to receiving, accepting, and completing a message).
They may be used for:
tracing methods,
control scheduling (see Section 'Scheduling concurrency:'),
step execution (by calling method halt),
broadcast changes (for instance to views in a MVC dependencies framework),
etc...
They are actually used by the system itself for some of the synchronization classes
(for instance to update synchronization counters in class CountersActorBehavior).

Their main use at the user level is for tracing events.
Class ActorBehavior actually includes class methods ('setTrace:' and others)
to automatically generate tracing methods for a given class.
(See class ActorBehavior comment.)


Scheduling concurrency:
-----------------------

Actalk provides concurrent activities, thanks to the standard multi processing
facility of Smalltalk-80.
However standard Smalltalk-80 scheduler does not provide time-slicing.
That is a process may keep the processor until termination
(unless there are other higher priority processes preempting it).
This is not very satisfactory to simulate fair concurrency between activities.

By evaluating the expression 'Processor yield', one may (explicitly)
force the way to other processes.
In order to avoid putting such control statements within the programs,
the programmer may use generic event methods
(see Section 'Generic event methods:' above) to include 'Processor yield'.
This solution is abstract enough, but is unfortunately not fully complete.
This is because private routines won't be affected by generic events.
Also scheduling as explicitly triggered by 'Processor yield' is not
necessarily very fair between activities.

In order to provide a more complete solution,
we currently include within the platform libraries a minimal extension
to provide time-slicing (implicit fair sharing of processor between processes).
This is a small goodies written by Hubert Baumeister, at Dortmund University,
and provided through the Manchester Smalltalk Archive Library.
(See class ProcessorScheduler class methods protocol 'slc'.
Note that you then need to protect/serialize the Transcript window,
see class SharedTextCollector comment.)

Further work will port and integrate a more elaborate time-slicing scheduler
which was developed in Actalk version 2.


Starting up:
------------

To start up, first look at category Actalk-Examples,
and look for comments of the classes
and also for class methods protocols examples.

You may then start to explore other extension categories and related examples.

Note that class ActorBehavior is the entry point class of Actalk.
ActorBehavior provides some useful class methods to trace events
(receiving, accepting and completing a message), and also to terminate/clean up actors.
(This latter facility happens to be necessary to help the garbage collector
recovering actors. See section 'Warnings:'.)


Warnings:
---------

Actalk has some specificities in terms of the behavior of actors
and the way standard Smalltalk-80 programming tools may work on them.

Errors.

In case of error within an actor (for instance: does not understand a message)
its behavior process is then stopped.
Then you have to proceed in the notifier or debugger window
or to reset it if you want the actor behavior to resume its activity.
(Note that actually we often happen to just restart the whole program
with a brand new set of objects and actors).

An important issue is that the debugger only shows the stack of messages of the
current behavior/process. Information about the sender has been lost,
because of the asynchronous transmission.
A simple prototype debugger reconstructing such links had been designed for Actalk
version 1 (at the expense of transparently expanding messages in order to convey the
context of the sender).
We have to eventually port and integrate this extended debugger within current version.

Garbage collection of processes.

Smalltalk-80 standard garbage collector happens not to recover processes
which are waiting onto a semaphore even if both the process and the semaphore
are not referenced (any more).
Meanwhile we could consider that such a process could never restart because
the semaphore will never signaled, being not referenced.
And as consequence in theory it could be recovered by a garbage collector
(although currently it is not).

Actually Actalk actors are implemented with some infinite process
looping over accepting messages taken from the mail queue.
Once some actor is no more referenced, it will eventually consume all pending
messages, and no further message could ever reach him.
As a consequence, its behavior process will wait forever onto its empty
mail queue.
And as explained above, unfortunately the process won't be recovered by the
garbage collector.
(And we have no access to Smalltalk-80 standard garbage collector
to possibly extend it accordingly).

This results in an important consequence. The programmer MUST do some
cleanups from time to time in order to help the garbage collector to recover
these resources.
(Otherwise after creation of a very large number of actors,
the memory could eventually get exhausted).
Cleanup consists in terminating behavior processes
of actors which are no more used.

Class ActorBehavior provides two methods to cleanup all instances of a class
(class method 'cleanUp')
and within a full class hierarchy (class method 'allCleanUp').
(See class ActorBehavior comment.)

One disciplined way of handling this limitation is also to specify
termination for actors not expected to be used anymore
(that is not expected to receive any further message).
Examples are short-lived actors, such as continuations, where we may expect a
fixed number of incoming messages (often just one).
Thus they may precompute their termination.
Actalk offers such kinds of bounded processes for library classes of
continuations.
See categories Actalk-Kernel-ReplyDest and Actalk-Kernel-JoinCont.


Publications:
-------------

There are several publications covering various aspects of the
Actalk project and system, although they may be a little out of date
for covering recent extensions included within this version.

A report collects the main publications on the Actalk project
at LITP research lab during 1989-1992.
Included papers (five) introduce and describe the Actalk platform,
survey its applications, discuss its pedagogical goals,
and describe its programming environment for visualizing and controlling
concurrent activities:

	Selection of Publications on the Actalk Project,
	J.-P. Briot, L. Lescaudron, M. Bouabsa,
	LITP 92-68 Research Report,
	Institut Blaise Pascal, Paris, France,
	September 1992.

One of the included papers has been published at ECOOP'89 Conference
and introduces and surveys the Actalk platform.
It discusses its designs goals,	and details the implementation of the Actalk
kernel. The paper includes two examples of simulating constructs of OOCP
languages (Actor model and ABCL/1 language) by subclassing the Actalk kernel:

	Actalk: a Testbed for Classifying and Designing Actor Languages
	in the Smalltalk-80 Environment,
	J.-P. Briot,
	Proceedings of the European Conference on Object-Oriented Programming
	(ECOOP'89),
	edited by S. Cook,
	British Computer Society Workshop Series,
	Cambridge University Press,
	United-Kingdom,
	pages 109-129,
	July 1989.

A technical report (actually the initial report on Actalk) describes and
discusses extensively (57 pages) the implementation of the kernel of Actalk,
its extensions, and several examples:

	From Objects to Actors: Study of a Limited Symbiosis in Smalltalk-80,
	J.-P. Briot,
	LITP 88-58 RXF Research Report,
	Institut Blaise Pascal, Paris, France,
	September 1988.

These papers, as well as others, may be recovered through anonymous ftp or WWW/Mosaic.
See info file README for access information.


Author(s):
----------

Actalk version 3 is currently being developed by Jean-Pierre Briot.
However many other people contributed (and will still contribute, we hope!)
to the history of its development. See section 'Acknowledgements:' below.


Acknowledgements:
-----------------

Actalk version 1 has been initially designed and developed by Jean-Pierre Briot.
Loic Lescaudron designed and implemented version 2,
including programming environment tools.
We sincerely thank him for his prime contribution to the development
of Actalk.

Other contributors are people who developed some parts, some experiments,
or some systems built upon Actalk foundation:

the GLA DESS program, University Pierre et Marie Curie, Paris,
who developed the initial extended MVC framework,
including Gilles Moussion, who developed the initial time-slicing scheduler,
and Pierre Abramovici, who developed a prototype multi-agent system (Agentalk);

Malik Bouabsa, LITP, Paris, who designed an extended window mechanism
for version 2 (in Smalltalk-80 version 2.5);

Sylvie Lemarie, LITP, Paris, studied the transposition of the Actalk model
to C++ and its distributed implementation onto transputers;

the DESS program, Nantes University, supervised by Jean Bezivin and
Olivier Roux, who developed many Actalk extensions (POOL, OCCAM, CSP,
Synchronization Counters,...). (Actually their implementation of POOL and
Synchronization Counters has been integrated and revised within current
version 3);

the multi-agents research team headed by Jacques Ferber, Laforia, Paris,
and more specifically Alexis Drogoul, Thierry Bouron and Claude Delaye,
who developed various Actalk-based multi-agents platforms (Ecotalk, Magentalk);

Sylvain Giroux, University of Montreal, who developed a reflexive system
based on Actalk, named ReActalk;

Annick Fron, who recently transposed an experimental constraint solving system
into a concurrent version implemented in Actalk;

A key supporter of Actalk through his feedback
is also Jean-Francois Perrot, Laforia, Paris.

We also thank Akinori Yonezawa for his current support,
as well as people within his lab, notably Jeff McAffer and Laurent Thomas
for several discussions about OOP, concurrency, reflection,
and... Smalltalk of course!

We thank everybody for their contribution and feedback,
and we hope that this list will keep growing!


Influences:
-----------

Key influences for Actalk are following:

ConcurrentSmalltalk (Yasuhiro Yokote and Mario Tokoro, OOPSLA'86&87)
as a OOCP language based on Smalltalk.

Simtalk (Jean Bezivin, OOPSLA'87) as a testbed using Smalltalk-80
to classify and compare various simulation models and constructs.
Simtalk includes implementation of various synchronization policies
(monitors,...) for concurrent activities.
We owe a lot to Simtalk for showing us the way of a
Smalltalk-based testbed for studying various models and constructs.
In some way Simtalk and Actalk are complementary as Simtalk focus is more on
simulation and synchronization of processes on passive shared data,
whereas Actalk exclusive focus is on languages with the notion of
active objects.

All OOCP languages modeled within Actalk extensions (Actors, ABCL/1, POOL...)
have been, needless to say, influences to Actalk.


Last words:
-----------

Have fun!
The development of Actalk is still in progress...
We are welcoming any feedback (good or not) from you!


Date:
-----

8 April 1994
Jean-Pierre Briot
