From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id pBVGs3UO018513 for ; Sat, 31 Dec 2011 17:54:03 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcCADI9/07RVaG2kGdsb2JhbAApEAqEP1CXTIdoAYgICCIBAQEBCQkNBxQEIYIFBgIPBBkBGx4DEgMNNwIkAREBBQEiLgeHYCOUfoJbCosdSIJrhAM/iHECBQuIS4IjgRYElQKNfT2Dew X-IronPort-AV: E=Sophos;i="4.71,436,1320620400"; d="scan'208";a="137376083" Received: from mail-gx0-f182.google.com ([209.85.161.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 31 Dec 2011 17:53:57 +0100 Received: by ggnp1 with SMTP id p1so14307517ggn.27 for ; Sat, 31 Dec 2011 08:53:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=W7MaKcpWcnEzHd5WQDUii2pFiChfKxELhCyLEvEooUs=; b=mnFyHykSLO+px1EA8c+pjlR3+0Y5+zQRwUOVJvRzRCDb0cAioZ9YwxLVKJV0DpEHqX OgleKo4rHUNIjq82LnYDC11TmgALqerJkjVsGv7rvCDgi0BQC2EqICnS3tmpj9JVQ2+8 ugvn3vP+zVBXKGiD8JVRl+mPsb8hyUW176Ato= Received: by 10.101.61.5 with SMTP id o5mr17916086ank.37.1325350435592; Sat, 31 Dec 2011 08:53:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.107.136 with HTTP; Sat, 31 Dec 2011 08:53:34 -0800 (PST) From: Pierre-Alexandre Voye Date: Sat, 31 Dec 2011 17:53:34 +0100 Message-ID: To: caml-list Content-Type: multipart/alternative; boundary=001636ed690fea990b04b566317c Subject: [Caml-list] What type strategy ? --001636ed690fea990b04b566317c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [There's a french version below] Hello, I am currently developing a multi agent system engine in Ocaml, and although a first version of this engine works really well, I have some difficulties to generalize the engine to any kind of agent. The difficulty comes from the organization, in particular strategy of typing that I chose. My engine can animate agents - which are represented by objects - with a hierarchical finite state machine. In such an automaton, each state can contains a finite state automata that will be activated in this state.Thus, one can define different behaviors and sub behavior in the agent. I'm not very good at schematic, but here is one, to illustrate: http://imagepaste.nullnetwork.net/viewimage.php?id=3D3044 Transitions are suitable for SMA: they pass from internal conditions, but external events. It is evaluated on the agent, or the event using a Boolean function: type ('agent' event) transition =3D Condition of (agent -> bool) | Event of ('event -> bool) | EventOr of ('event -> bool) * (' agent 'event) transition | EventAnd of ('event -> bool) * (' agent 'event) transition | EventXor of ('event -> bool) * (' agent 'event) transition | EventNot of ('event -> bool) | ConditionOr of (agent -> bool) * ('agent' event) transition | ConditionAnd of (agent -> bool) * ('agent' event) transition | ConditionXor of (agent -> bool) * ('agent' event) transition | ConditionNot of (agent -> bool); We can define any Boolean equation to define a simple transition. Now my code is organized as follows: - Class "state" manages the state and seeks what transition applies. Of course, what is in this class performed the functions (agent -> bool) or ('event -> bool) which involves the acquisition of the static type. Each state possesses all the possible transitions to other instance of "state". - A class "directory" that allows you to associate each agent to a identifier string, because the events are designed to be sent from the outside (HTTP or other). Typically, an event can be a command that the user sends to the controller. - A class "masEvent" which can receive events from the outside, to identify agents which are involved by the event. - A class "agent" that embeds all the state transition diagram of the agent. It was he who receives "emails" including a masEvent. His method "cycle" is used to start the process of moving (if applicable) to another state. The objective: my goal is to manage any kind of agent, which would ideally objects inheriting from "agent". These objects do not redefine methods, they just add new data and methods. If I am willing to rewrite everything as a module, I would like at least that the agents to remain objects in order to manage their mutable datas. The problem: It is very difficult to ensure that the "state" object knows all objects inheriting from "agent", but it is essential to ensure the compiler accepts it. My current solution is to give two agents as generic type to state: class ['typeAgent' objetDuJeu] state (myAgent 'typeAgent) =3D object (self) during its instantiation, but it is very inconvenient because it implies that we must do the same for objects and annaire masEvent: class ['typeAgent, item] masEvent (directory) =3D object (self) ... ['TypeAgent, item] directory (myAgent, myObj) =3D object (self) ... Indeed, "directory" must know all types inheriting from agents. This solution isn't flexible and implies a lot of problems. Solutions i though : - Define all objects which inherits from "agent" as virtual and redefine true class which inherits really from these virtual class, it's very tricky... - Rewrite state, masEvent, directory as module ? My question is this: what I could choose smart strategy to ensure that "state" can easily manage any kind can be agents, with only constraints they inherit "agent"? Thank you Fran=C3=A7ais : Bonjour, je suis en train de d=C3=A9velopper un moteur Syst=C3=A8me Multi Agent en O= caml, et bien qu'une premi=C3=A8re version de ce moteur fonctionne tr=C3=A8s bien, j= 'ai quelques difficult=C3=A9s =C3=A0 le g=C3=A9n=C3=A9raliser =C3=A0 toute sort= e d'agent. Cette difficult=C3=A9 tient =C3=A0 l'organisation, =C3=A0 la strat=C3=A9gie de ty= page que j'ai choisi (et au fait que j'ai r=C3=A9ellement d=C3=A9couvert ocaml pendant son =C3= =A9criture :-) ). Mon moteur permet d'animer des agents, qui sont mat=C3=A9rialis=C3=A9s par = des objets, avec un automate =C3=A0 =C3=A9tat fini hi=C3=A9rarchique. Dans un t= el automate, chaque =C3=A9tat peut abriter un automate qui va s'activer lorsqu'on passe = dans cet =C3=A9tat. Ainsi imbriqu=C3=A9s, on peut d=C3=A9finir divers comporteme= nts et sous comportements de l'agent. Je ne suis pas tr=C3=A8s bon pour les sch=C3=A9mas, mais en voici un : http://imagepaste.nullnetwork.net/viewimage.php?id=3D3044 Les transitions sont adapt=C3=A9 =C3=A0 un SMA : elles se font =C3=A0 parti= r des conditions internes, mais aussi des =C3=A9v=C3=A8nements ext=C3=A9rieur. On= =C3=A9value sur l'agent, ou sur l'=C3=A9v=C3=A8nement une fonction rendant un bool=C3=A9en : type ('agent, 'event) transition =3D Condition of ('agent -> bool) | Event of ('event -> bool) | EventOr of ('event -> bool) * ('agent,'event) transition | EventAnd of ('event -> bool) * ('agent,'event) transition | EventXor of ('event -> bool) * ('agent,'event) transition | EventNot of ('event -> bool) | ConditionOr of ('agent -> bool) * ('agent,'event) transition | ConditionAnd of ('agent -> bool) * ('agent,'event) transition | ConditionXor of ('agent -> bool) * ('agent,'event) transition | ConditionNot of ('agent -> bool);; On peut ainsi d=C3=A9finir n'importe quelle =C3=A9quation bool=C3=A9enne si= mple pour d=C3=A9finir une transition. Aujourd'hui mon code est organis=C3=A9 comme suit : - Une classe "state" g=C3=A8re les =C3=A9tat, et cherche quel transition s= 'applique. Bien entendu, c'est dans cette classe qu'est ex=C3=A9cut=C3=A9 les fonction= s ('agent -> bool) ou ('event -> bool) qui implique d'avoir connaissance du type statique de chaque agents. Chaque state, poss=C3=A8de l'ensemble des transi= tions possible vers d'autres instance de "state". - Une classe annuaire qui permet d'associer chaque agent a un identifiant de type string, en effet les =C3=A9v=C3=A8nements sont con=C3=A7us pour =C3= =AAtre envoy=C3=A9 depuis l'ext=C3=A9rieur (requete http ou autre). Typiquement, un =C3=A9v=C3=A8neme= nt peut =C3=AAtre une commande que l'utilisateur envoie =C3=A0 l'automate. - une classe "masEvent" qui permet de recevoir les =C3=A9v=C3=A8nements de l'ext=C3=A9rieur et d'identifier les agents que l'=C3=A9v=C3=A8nement impli= que (l'=C3=A9v=C3=A8nement doit fournir les identifiants) - Une classe "agent" qui embarque tout le sch=C3=A9ma d'=C3=A9tat transitio= n de l'agent. C'est lui qui re=C3=A7oit des "emails" comprenant un masEvent. Sa m=C3=A9thode "cycle" permet de lancer le processus de passage ( s'il y a li= eu ) =C3=A0 un autre =C3=A9tat. L'objectif : mon objectif est de pouvoir g=C3=A9rer toute sorte d'agent, qui seraient dans l'id=C3=A9al, des objets h=C3=A9ritant de "agent". Ces objets ne red= =C3=A9finissent pas de m=C3=A9thodes, ils ajoutent des donn=C3=A9es et des nouvelles m=C3= =A9thodes. Si je suis pr=C3=AAt =C3=A0 tout r=C3=A9=C3=A9crire sous forme de module, = j'aimerai au moins que les agents restes des objets, afin de pouvoir g=C3=A9rer leur donn=C3= =A9es mutables. Le probl=C3=A8me : Il est tr=C3=A8s difficile de faire en sorte que l'objet state connaisse TOUS les objets h=C3=A9ritant de "agent", mais c'est indispensable pour que= le compilateur l'accepte. Ma solution actuelle consiste =C3=A0 donner 2 agents comme type g=C3=A9n=C3= =A9rique =C3=A0 state : class ['typeAgent, 'objetDuJeu] state (myagent :'typeAgent) =3D object (sel= f) lors de son instanciation, mais c'est tr=C3=A8s peu pratique parces que ce= la implique que l'on doivent faire de m=C3=AAme pour les objets annaire et mas= Event : class ['typeAgent,'objet] masEvent (annuaire ) =3D object (self) ... ['typeAgent,'objet] _ANNUAIRE (myAgent ,myObj ) =3D object (self) .= .. En effet, annaire doit connaitre tous les types h=C3=A9ritant de agents. Cette solution est absolument pas flexible et pose beaucoup de probl=C3=A8m= es. Solutions auxquelles j'ai pens=C3=A9 : - D=C3=A9finir une version "virtuelle" de chaque agents sp=C3=A9cialis=C3= =A9 cens=C3=A9 h=C3=A9riter de "agent", afin que state les "connaissent" ? - Transformer "state", "masEvent" et "annuaire" en module, mais pour quel apport ? Ma question est donc la suivante : quelle strat=C3=A9gie intelligente je pourrais choisir pour faire en sorte que "state" puisse g=C3=A9rer ais=C3= =A9ment toute sorte possible d'agents, avec seules contraintes qu'ils h=C3=A9ritent= de "agent" ? Merci Regards, Pierre-Alexandre --=20 --------------------- https://twitter.com/#!/ontologiae/ http://linuxfr.org/users/montaigne --001636ed690fea990b04b566317c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable [There's a french version below]

Hello,
I am currently develo= ping a multi agent system engine in Ocaml, and although a first version of = this engine works really well, I have some difficulties to generalize the e= ngine to any kind of agent. The difficulty comes from the organization, in = particular strategy of typing that I chose.

My engine can animate agents - which are represented by objects - with = a hierarchical finite state machine. In such an automaton, each state can c= ontains a finite state automata that will be activated in this state.Thus, = one can define different behaviors and sub behavior in the agent.

I'm not very good at schematic, but here is one, to illustrate:
= http:= //imagepaste.nullnetwork.net/viewimage.php?id=3D3044


Transit= ions are suitable for SMA: they pass from internal conditions, but external= events. It is evaluated on the agent, or the event using a Boolean functio= n:

type ('agent' event) transition =3D
=C2=A0=C2=A0 Condition o= f (agent -> bool)
=C2=A0 | Event of ('event -> bool)
=C2=A0= | EventOr of ('event -> bool) * (' agent 'event) transition=
=C2=A0 | EventAnd of ('event -> bool) * (' agent 'event)= transition
=C2=A0 | EventXor of ('event -> bool) * (' agent 'event) tra= nsition
=C2=A0 | EventNot of ('event -> bool)
=C2=A0 | Conditi= onOr of (agent -> bool) * ('agent' event) transition
=C2=A0 |= ConditionAnd of (agent -> bool) * ('agent' event) transition
=C2=A0 | ConditionXor of (agent -> bool) * ('agent' event) trans= ition
=C2=A0 | ConditionNot of (agent -> bool);

We can define = any Boolean equation to define a simple transition.

Now my code is o= rganized as follows:

- Class=C2=A0 "state" manages the state and seeks what transi= tion applies. Of course, what is in this class performed the functions (age= nt -> bool) or ('event -> bool) which involves the acquisition of= the static type. Each state possesses all the possible transitions to othe= r instance of "state".
- A class "directory" that allows you to associate each agent to = a=C2=A0 identifier string, because the events are designed to be sent from = the outside (HTTP or other). Typically, an event can be a command that the = user sends to the controller.
- A class "masEvent" which can receive events from the outside, t= o identify agents which are involved by the event.
- A class "agent= " that embeds all the state transition diagram of the agent. It was he= who receives "emails" including a masEvent. His method "cyc= le" is used to start the process of moving (if applicable) to another = state.


The objective:
my goal is to manage any kind of agent, which wou= ld ideally objects inheriting from "agent". These objects do not = redefine methods, they just add new data and methods.
=C2=A0If I am will= ing to rewrite everything as a module, I would like at least that the agent= s to remain objects in order to manage their mutable datas.

The problem:
It is very difficult to ensure that the "state&quo= t; object knows all objects inheriting from "agent", but it is es= sential to ensure the compiler accepts it.

My current solution is to= give two agents as generic type to state:
class ['typeAgent' objetDuJeu] state (myAgent 'typeAgent) =3D o= bject (self)

=C2=A0during its instantiation, but it is very inconven= ient because it implies that we must do the same for objects and annaire ma= sEvent:

class ['typeAgent, item] masEvent (directory) =3D object (self) ...=
['TypeAgent, item] directory (myAgent, myObj) =3D object (self) ...=

Indeed, "directory" must know all types inheriting from a= gents.
This solution isn't flexible and implies a lot of problems.

Solu= tions i though :
- Define all objects which inherits from "agent&q= uot; as virtual and redefine true class which inherits really from these vi= rtual class, it's very tricky...
- Rewrite state, masEvent, directory as module ?

My question is this= : what I could choose smart strategy to ensure that "state" can e= asily manage any kind can be agents, with only constraints they inherit &qu= ot;agent"?

Thank you





Fran=C3=A7ais :
Bonjour,
je suis= en train de d=C3=A9velopper un moteur Syst=C3=A8me Multi Agent en Ocaml, e= t bien qu'une premi=C3=A8re version de ce moteur fonctionne tr=C3=A8s b= ien, j'ai quelques difficult=C3=A9s =C3=A0 le g=C3=A9n=C3=A9raliser =C3= =A0 toute sorte d'agent. Cette difficult=C3=A9 tient =C3=A0 l'organ= isation, =C3=A0 la strat=C3=A9gie de typage que j'ai choisi (et au fait= que j'ai r=C3=A9ellement d=C3=A9couvert ocaml pendant son =C3=A9critur= e :-) ).

Mon moteur permet d'animer des agents, qui sont mat=C3=A9rialis=C3= =A9s par des objets, avec un automate =C3=A0 =C3=A9tat fini hi=C3=A9rarchiq= ue. Dans un tel automate, chaque =C3=A9tat peut abriter un automate qui va = s'activer lorsqu'on passe dans cet =C3=A9tat. Ainsi imbriqu=C3=A9s,= on peut d=C3=A9finir divers comportements et sous comportements de l'a= gent.

Je ne suis pas tr=C3=A8s bon pour les sch=C3=A9mas, mais en voici un :<= br>ht= tp://imagepaste.nullnetwork.net/viewimage.php?id=3D3044


Les = transitions sont adapt=C3=A9 =C3=A0 un SMA : elles se font =C3=A0 partir de= s conditions internes, mais aussi des =C3=A9v=C3=A8nements ext=C3=A9rieur. = On =C3=A9value sur l'agent, ou sur l'=C3=A9v=C3=A8nement une foncti= on rendant un bool=C3=A9en :

type ('agent, 'event) transition =3D
=C2=A0=C2=A0 Condition= =C2=A0=C2=A0=C2=A0=C2=A0 of ('agent -> bool)
=C2=A0 | Event=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of ('event=C2=A0 -> bool) =C2=A0 | EventOr=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of ('event -> bool)= * ('agent,'event) transition
=C2=A0 | EventAnd=C2=A0=C2=A0=C2=A0=C2=A0 of ('event -> bool) * (= 9;agent,'event) transition
=C2=A0 | EventXor=C2=A0=C2=A0=C2=A0=C2=A0= of ('event -> bool) * ('agent,'event) transition
=C2=A0 = | EventNot=C2=A0=C2=A0=C2=A0=C2=A0 of ('event -> bool)
=C2=A0 | = ConditionOr=C2=A0 of ('agent -> bool) * ('agent,'event) tran= sition
=C2=A0 | ConditionAnd of ('agent -> bool) * ('agent,'event) = transition
=C2=A0 | ConditionXor of ('agent -> bool) * ('agen= t,'event) transition
=C2=A0 | ConditionNot of ('agent -> bool= );;

On peut ainsi d=C3=A9finir n'importe quelle =C3=A9quation bool=C3=A9enn= e simple pour d=C3=A9finir une transition.

Aujourd'hui mon code = est organis=C3=A9 comme suit :

- Une classe "state" g=C3= =A8re les =C3=A9tat, et cherche quel=C2=A0 transition s'applique. Bien = entendu, c'est dans cette classe qu'est ex=C3=A9cut=C3=A9 les fonct= ions ('agent -> bool) ou ('event -> bool) qui implique d'= avoir connaissance du type statique de chaque agents. Chaque state, poss=C3= =A8de l'ensemble des transitions possible vers d'autres instance de= "state".
- Une classe annuaire qui permet d'associer chaque agent a un identifia= nt de type string, en effet les =C3=A9v=C3=A8nements sont con=C3=A7us pour = =C3=AAtre envoy=C3=A9 depuis l'ext=C3=A9rieur (requete http ou autre). = Typiquement, un =C3=A9v=C3=A8nement peut =C3=AAtre une commande que l'u= tilisateur envoie =C3=A0 l'automate.
- une classe "masEvent" qui permet de recevoir les =C3=A9v=C3=A8n= ements de l'ext=C3=A9rieur et d'identifier les agents que l'=C3= =A9v=C3=A8nement implique (l'=C3=A9v=C3=A8nement doit fournir les ident= ifiants)
- Une classe "agent" qui embarque tout le sch=C3=A9ma= d'=C3=A9tat transition de l'agent. C'est lui qui re=C3=A7oit d= es "emails" comprenant un masEvent. Sa m=C3=A9thode "cycle&q= uot; permet de lancer le processus de passage ( s'il y a lieu ) =C3=A0 = un autre =C3=A9tat.


L'objectif :
=C2=A0=C2=A0=C2=A0 mon objectif est de pouvoir= g=C3=A9rer toute sorte d'agent, qui seraient dans l'id=C3=A9al, de= s objets h=C3=A9ritant de "agent". Ces objets ne red=C3=A9finisse= nt pas de m=C3=A9thodes, ils ajoutent des donn=C3=A9es et des nouvelles m= =C3=A9thodes.
=C2=A0Si je suis pr=C3=AAt =C3=A0 tout r=C3=A9=C3=A9crire sous forme de mod= ule, j'aimerai au moins que les agents restes des objets, afin de pouvo= ir g=C3=A9rer leur donn=C3=A9es mutables.

Le probl=C3=A8me :
=C2= =A0=C2=A0=C2=A0 Il est tr=C3=A8s difficile de faire en sorte que l'obje= t state connaisse TOUS les objets h=C3=A9ritant de "agent", mais = c'est indispensable pour que le compilateur l'accepte.

Ma solution actuelle consiste =C3=A0 donner 2 agents comme type g=C3=A9= n=C3=A9rique =C3=A0 state :
class ['typeAgent, 'objetDuJeu] stat= e (myagent :'typeAgent) =3D object (self)

=C2=A0lors de son inst= anciation, mais c'est tr=C3=A8s peu pratique parces que cela implique q= ue l'on doivent faire de m=C3=AAme pour les objets annaire et masEvent = :

class ['typeAgent,'objet] masEvent (annuaire ) =3D object (self= ) ...
['typeAgent,'objet]=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 _ANNUAIRE=C2=A0 (myAgent ,myObj ) =3D object (self) ...

En effet= , annaire doit connaitre tous les types h=C3=A9ritant de agents.

Cette solution est absolument pas flexible et pose beaucoup de probl=C3= =A8mes.

Solutions auxquelles j'ai pens=C3=A9 :
- D=C3=A9finir= une version "virtuelle" de chaque agents sp=C3=A9cialis=C3=A9 ce= ns=C3=A9 h=C3=A9riter de "agent", afin que state les "connai= ssent" ?
- Transformer "state", "masEvent" et "annuaire&quo= t; en module, mais pour quel apport ?


Ma question est donc la su= ivante : quelle strat=C3=A9gie intelligente je pourrais choisir pour faire = en sorte que "state" puisse g=C3=A9rer ais=C3=A9ment toute sorte = possible d'agents, avec seules contraintes qu'ils h=C3=A9ritent de = "agent" ?

Merci



Regards,
Pierre-Alexandre

= --
---------------------
https://twitter.com/#!/ontologiae/
http://linuxfr.or= g/users/montaigne

--001636ed690fea990b04b566317c--