Ambient-Oriented Programming

User Tools

Site Tools

Trace:
at:tutorial:actors

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
at:tutorial:actors [2008/03/13 16:49] – added tvcutsemat:tutorial:actors [2008/11/03 10:00] – added tvcutsem
Line 26: Line 26:
   };   };
 }; };
->><far ref to:<object:1555668>>+>><far ref:behaviour of <actormirror:9501984>>
 </code> </code>
  
Line 70: Line 70:
   };   };
 }; };
->><far ref to:<object:11600335>>+>><far ref:behaviour of <actormirror:14115383>>
 </code> </code>
  
Line 112: Line 112:
   };   };
 }; };
->><object:15603573[<type tag:Isolate>]>+>><obj:{super,super:=,re,re:=,im,im:=,...}[Isolate]>
 </code> </code>
  
Line 196: Line 196:
  
 The first statement imports the futures module into the current lexical scope. This enables you as a developer to use some additional language constructs exported by the futures module, as will be explained later. The second statement enables the futures behaviour, causing any asynchronous message send to return a future rather than ''nil''. If ''false'' is passed to the call to ''enableFutures'', only messages marked explicitly as a ''FutureMessage'' will return a future. The first statement imports the futures module into the current lexical scope. This enables you as a developer to use some additional language constructs exported by the futures module, as will be explained later. The second statement enables the futures behaviour, causing any asynchronous message send to return a future rather than ''nil''. If ''false'' is passed to the call to ''enableFutures'', only messages marked explicitly as a ''FutureMessage'' will return a future.
 +
 +More information pertaining to the API of the futures language module can be found in the [[:at:tutorial:appendix#futures_and_multifutures|appendix]].
  
 ==== Working with Unresolved Futures ==== ==== Working with Unresolved Futures ====
Line 317: Line 319:
  
 <code> <code>
 +// to create an explicit future:
 def [future, resolver] := makeFuture(); def [future, resolver] := makeFuture();
-consumer<-give(future); + 
-def val := /* calculate useful value */+// to explicitly resolve a future
 resolver.resolve(val); resolver.resolve(val);
 </code> </code>
Line 326: Line 329:
  
 The resolver also defines a ''ruin(e)'' method which can be used to explicitly ruin a future, causing any attached ''when:becomes:catch:'' blocks to trigger their ''catch:'' clause. The resolver also defines a ''ruin(e)'' method which can be used to explicitly ruin a future, causing any attached ''when:becomes:catch:'' blocks to trigger their ''catch:'' clause.
 +
 +As an example of such conditional synchronization, consider the following example first proposed by Henry Lieberman in his 1987 paper on "Object-oriented Programming in ACT-1". A dating service allows lonely hearts to register their profile allowing it to match people based on their profiles. The dating service can be modelled as an object:
 +
 +<code>
 +def makeDatingService() {
 +  def people := []; // a list of Questionnaire objects
 +  object: {
 +    def match(lonelyHeart) {
 +      // if an ideal mate is found in the list,
 +      //   return its name
 +      // otherwise
 +      //   create a future (a "promise") to answer
 +      //   the lonelyHeart later, when an ideal made
 +      //   has registered with the dating service
 +    }
 +  }
 +}
 +</code>
 +
 +Let us assume that a person is simply identified by a name and its sex:
 +<code>
 +def makePerson(nam, sx) {
 +  object: {
 +    def name := nam;
 +    def sex := sx;
 +  }
 +};
 +</code>
 +
 +The dating service has a little database stored as a simple list. This list does not contain person objects but rather Questionnaire objects. The questionnaire contains the logic necessary to match people. We will assume for the sake of the example that 2 people match if they are of the opposite sex. In addition, a questionnaire object can keep track of an "outstanding answer" (which we model as a first-class future) for a lonely heart that is still waiting for his or her perfect match.
 +
 +<code>
 +def makeQuestionnaire(p) {
 +  def idealPersonResolver;
 +  object: {
 +    def person := p;
 +    def matches(otherQ) { otherQ.person.sex != p.sex };
 +    def wait() {
 +      def [future, resolver] := makeFuture();
 +      idealPersonResolver := resolver;
 +      future
 +    };
 +    def notify(name) { idealPersonResolver.resolve(name) };
 +  };
 +};
 +</code>
 +
 +When a questionnaire is asked to ''wait()'', it returns a future and stores the future's corresponding resolver in a hidden field. Later, when a matching person is found, the future can be explicitly resolved by invoking the questionnaire's ''notify'' method.
 +
 +Armed with these abstractions, we can now fill in the missing logic of the ''match'' method of the dating service:
 +
 +<code>
 +def makeDatingService() {
 +  def people := []; // a list of Questionnaire objects
 +  object: {
 +    def match(lonelyHeart) {
 +      def lonelyHeartQ := makeQuestionnaire(lonelyHeart);
 +      { |return|
 +        people.each: { |idealMateQ|
 +          // an ideal mate was found
 +          if: (idealMateQ.matches(lonelyHeartQ).and: { lonelyHeartQ.matches(idealMateQ) }) then: {
 +            idealMateQ.notify(lonelyHeart.name); // notify idealMate
 +            // remove the person from the database
 +            people := people.filter: { |q| q != idealMateQ };
 +            return(idealMateQ.person.name) // notify lonelyHeart
 +          }
 +        };
 +        // no ideal mate was found, store its questionnaire in the database
 +        people := people + [lonelyHeartQ];
 +        lonelyHeartQ.wait(); // return a future for the ideal person's name
 +      }.escape();
 +    }
 +  }
 +}
 +</code>
 +
 +Below, we define an auxiliary method that illustrates how a lonely heart has to interact with the dating service.
 +
 +<code>
 +def d := makeDatingService();
 +def register(p) {
 +  when: d<-match(p)@FutureMessage becomes: { |name|
 +    system.println(p.name + " matched with " + name);
 +  };
 +};
 +</code>
 +
 +The key to our conditional synchronization is that the ''when:becomes:'' listener will only be invoked if and when a matching person has registered itself with the dating service. As long as this condition has not been fulfilled, the future will remain unresolved. In fact, the future returned by ''d<-match(p)'' has been resolved with another future, the one returned by ''Questionnaire.wait()''. However, recall that a future resolved by another unresolved future does not really count as being "resolved" and will only trigger its listeners once its "dependent" future has been resolved.
  
 ===== Actor Mirrors ===== ===== Actor Mirrors =====
Line 331: Line 422:
 An actor in AmbientTalk is primarily a //host// for regular objects. It is equipped with a message queue to receive asynchronous messages sent to one of its objects. The mirrors on these objects have corresponding meta-level operations such as ''send'' and ''receive'' that can be overridden to customise e.g. message sending on a per-object basis. An actor in AmbientTalk is primarily a //host// for regular objects. It is equipped with a message queue to receive asynchronous messages sent to one of its objects. The mirrors on these objects have corresponding meta-level operations such as ''send'' and ''receive'' that can be overridden to customise e.g. message sending on a per-object basis.
  
-Some operations, such as creating and sending asynchronous messages are useful to reify at the //actor level//. With such a reification, the programmer could override the way messages are sent by any object from within an actor. The mirror on an actor that reifies these operations is bound to the ''actor'' variable, defined at top-level. Evaluating ''actor'' returns the mirror on the current actor. It defines operations such as ''createMessage'' and ''send'' which can be explicitly invoked, or even overridden by the programmer.+Some operations, such as creating and sending asynchronous messages are useful to reify at the //actor level//. With such a reification, the programmer could override the way messages are sent by any object from within an actor. The mirror on an actor that reifies these operations can be acquired by invoking the function ''reflectOnActor()'', defined at top-level. Evaluating ''reflectOnActor'' returns the mirror on the current actor. It defines operations such as ''createMessage'' and ''send'' which can be explicitly invoked, or even overridden by the programmer.
  
-Overriding the actor's metaobject protocol can be done by //installing// a new protocol object. This is done by invoking the ''install:'' method on ''actor''. The following code installs a new MOP that logs any messages sent by any object in the current actor:+Overriding the actor's metaobject protocol can be done by //installing// a new protocol object. This is done by invoking the ''becomeMirroredBy:'' method on the actor's mirror. The following code installs a new MOP that logs any messages sent by any object in the current actor:
  
 <code> <code>
-def oldmirror := actor.install: (extend: actor with: {+def actor := reflectOnActor(); 
 +def oldmirror := actor.becomeMirroredBy: (extend: actor with: {
   def send(msg) {   def send(msg) {
     log(msg);     log(msg);
Line 344: Line 436:
 </code> </code>
  
-Notice that, in this example, the new metaobject protocol is an extension of the old protocol. This enables it to invoke its parent's behaviour simply by means of a super-send. Note also that the ''install:'' primitive returns the previously installed mirror. This is useful for when an actor mirror should only temporarily be installed. The old mirror can later be re-installed.+Notice that, in this example, the new metaobject protocol is an extension of the old protocol. This enables it to invoke its parent's behaviour simply by means of a super-send. Note also that the ''becomeMirroredBy:'' primitive returns the previously installed mirror. This is useful for when an actor mirror should only temporarily be installed. The old mirror can later be re-installed.
  
 <note> <note>
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag