URL: https://linuxfr.org/users/montaigne/journaux/le-langage-de-mes-r%C3%AAves Title: Le langage de mes rêves Authors: Ontologia Date: 2006年01月12日T13:36:06+01:00 Tags: Score: 0 Chers tous, je suis heureux de publier ici un brouillon de publication réalisée en collaboration avec Benoit Sonntag, décrivant un modèle de langage orienté agent en tant qu'extension du langage et compilateur Lisaac. Heureux, simplement parce qu'on voit le bout du tunnel après un mois de travail. Contrairement aux usages, je précède celle-ci d'une discussion sur l'interface entre la pensée et modélisation humaine et la machine, le langage. Ce langage a été conçu suite à mes piètres expériences de développement, à quelques lectures et réflexions ( [https://linuxfr.org/~Montaigne/19629.html](https://linuxfr.org/~Montaigne/19629.html) ) ainsi qu'a ma pratique parfois fastidieuse de la programmation qui a continuellement forgé ma conviction que ceux-ci sont encore nettement perfectibles. Depuis les début de l'ère informatique, le développeur se doit (c'est son rôle) d'adapter un cahier des charges pétris de préoccupations et représentation humaine en "code machine" basé fondamentalement sur l'idée de suivi automatique d'un graphe de code, qu'il soit objet ou procédurale avec des modes de représentations des informations fortement contraints par le fonctionnement intrinsèque et les limites de la machine. Celle-ci reste encore basée sur le modèle de Von Neumann. Il me semble que l'objectif doit rester clair et simple : _coller le mieux possible aux modes de représentations humain, à sa conception des processus l'environnant, et sa perception de la structure physique, biologique, sociétale, humaine (etc..) qui l'entoure._ Décrire un langage tentant d'atteindre cet objectif doit donner au développeurs le moyen d'exprimer le plus aisément leur intuition. Victoria Livchitz, dans l'interview que je traduisais il y a quelques mois ici même, exprimait cet opinion en l'illustrant d'exemples, d'analyses et de pistes de réflexions. J'avoue être au début du chemin, mais pense être engagé sur la bonne piste. Je distingue plusieurs éléments qu'il reste à creuser et structurer * Il faut une structuration ontologique d'un certain nombre de concepts et trouver un moyen de les chaîner entre eux. Il me semble que les recherches sur les ontologies sont d'inspiration trop dualiste pour y parvenir actuellement. Par exemple, une liste de couple de valeurs numériques peuvent faire apparaître (ou non) une structure d'espace vectoriel, avec tout ce que cela implique dans la possibilité de sémantiser le code. * Je pense que plus généralement, il faudrait trouver un moyen de se servir de cette ontologisation des langage afin de permettre de créer soi même ses propres primitives, Maître-esclave, reconnaissances de formes spécifiques, etc... * De façon plus terre à terre, il me semble indispensable de doter des objets (ou agent) d'etat pouvant évoluer et d'une possibilité de manipuler sémantiquement ses états, au début comme dans un langage du type de Prolog. * Le langage doit être capable de permettre une adaptation permanente au contexte en étant capable de s'adapter naturellement, chaque unité sachant redéfinir toute seul son rôle dans l'organisation. Cela nécessite une métadescription de l'unité logiciel (un objet, un agent, ou autre chose) permettant de décrire le rôle de celle-ci et _in fine_ de savoir s'adapter en adoptant par exemple un nouveau langage vers l'extérieur qui pourra lui être "appris" par la sémantique, c'est à dire en le rendant capable de réaliser des équivalences "conceptuelles" par reconnaissance de forme. Outre la reconnaissance de forme qui suppose intrinsèquement des ontologies selon moi, cela suppose un langage plus déclaratif et descriptif des buts que les langages actuels qui décrivent la structure d'un graphe. Outre ses considérations, il reste tout un champ de réflexion à ensemencer concernant entre autre la nature profonde du cause à effet, sa nature dans le cadre des phénomènes d'émergences systémiques (SMAs) , la place de la reconnaissance de forme dans la pensée humaine, la question de son implantation dans un langage, etc... J'avoue que ce concept de "cause à effet" me file entre les doigt à mesure que je tente de le dissequer. Un chantier passionnant en perspective. Un modèle tout à fait applicable aujourd'hui, déjà largement étudié, permet d'ors et déjà de s'abstraire de la logique selon laquelle un langage de programmation reste une simple description d'un graphe : il s'agit de la programmation concurrente voire orienté agent. C'est pour cela que j'ai cherché à concevoir un modèle de langage, au dessus du langage Lisaac (ceux qui me connaissent pourront se dire qu'on ne se refait pas...), cherchant à éliminer tout ce qui m'énerve dans la logique de programmation objet, par leurs manque. Bref. Voici la dissertation que j'ai rédigé avec l'aide indispensable de Benoit Sonntag. `**Introduction**` Bon nombre de logiciels sont modélisables en termes de petites unités logicielles collaborant ensemble afin de résoudre les problèmes qu'on lui soumet. On peut parler de fonctionnement émergeant. Les paradigmes de programmation objets ont considérablement amélioré la tâche du concepteur logiciel en lui apportant un mode de découpage plus proche d'un mode de pensée humaine. On peut d'ailleurs remarquer que la montée en niveau des langages de développement logiciel est concomittente à une proximité toujours plus accrue des modes de pensés et de réprésentations humains. Le paradigme objet trouve néanmoins ses limites dans la réalisation de logiciels excédents plusieurs dizaines de millions de lignes en imposant des architectures très complexes, peu souples et peu fiables. [citer Victoria Livshitz] Cette constatation nous a amené à imaginer un modèle entièrement dédié à simplifier la tâche du développeur et surtout à lui permettre d'exprimer au mieux son intuition. Nous pouvons synthétiser plusieurs caractéristiques : * Un être humain conceptualise le monde en terme d'objets animés ou non d'intentionnalités. * Les objets ont tendances à se comporter en fonction de stimuli extérieur. * Ces objets se transmettent des informations entre eux, et ces informations peuvent donner lieu à une modification d'un comportement. * Une cause implique un effet et vice-versa. * Les informations manipulés dans les programmes représentent des perceptions humaines, et possèdent donc une structure ontologique Notre modèle a pour objectif d'intégrer ces concepts tout en restant dans le cadre d'un langage objet à prototype classique. Si la modélisation d'une fourmillière nécessite un langage orienté agent, des calculs matriciels se satisfont parfaitement d'un langage orienté objet classique. Les deux approches sont complémentaires. Par conséquent, l'une des contraintes que nous avons imposé à notre modèle est de concevoir une extension élégante dans son uniformité au langage Lisaac. Ainsi, notre modèle respecte les grandes lignes de ce langage et en particulier son caractère typé. Les extensions ainsi prévu sont principalement orienté vers la conception de SMA réactifs et pulsionnels, l'approche par but étant particulièrement problématique à compiler d'une part et d'autre part s'intègre difficilement à un langage objet à prototype classique. Nous identifions plusieurs mécanismes permettant d'atteindre ce but : * Chaque agent doit pouvoir se comporter et réagir en fonction de son environnement direct. On défini donc des slots spécifiques, déclanchant un comportement si la clause est satisfaite * Il est nécessaire, pour aider le concepteur d'un SMA, de récupérer facilement des données sur un ensemble d'objets ou d'agents. Nous proposons un système d'extraction de données, inspiré d'SQL et adapté au modèle objet. Ici, un identifiant ou une référence d'un objet n'est plus nécessaire à son accès. * Les agents doivent pouvoir s'envoyer des messages en multicast en conditionnant la réception de ceux-ci à des critères définissable. * Le concepteur de SMA doit pouvoir posséder un outil lui permettant de représenter plusieurs niveau de systèmes multi-agent, un SMA pouvant être un agent d'un autre SMA. entre agent. Le choix du langage objet pour l'application de notre modèle agent se justifie essentiellement sur deux points cruciaux. Tout d'abord, les langages à classe reflètent d'une manière moins intuitive la vision que l'on peut donner à un agent. Le paradignme _classe/instance_ des langages à classe implique que la description statique d'un classe n'est pas directement présent et vivant dans l'univers de notre application. Une instance est alors nécessaire pour qu'un premier représentant d'une classe soit présent et vivant en mémoire. Une classe ne permet pas de visualiser celle-ci comme directement un agent, mais plutôt comme un schéma de construction d'un agent. A _contrario_, la description d'un prototype constitue directement un objet présent en mémoire, utilisable tel quel ou clonable si nécessaire. Ainsi, un prototype est directement en adéquation à l'image d'un premier "individu agent", comme Aden et Eve vivant dans notre SMA. Le second point est d'autre plus pragmatique. Si nous voulons démocratiser la programmation agent, de nombreux programmeur sont sensible à un point essentiel : les performances à l'exécution. Le langage Lisaac est actuellement l'unique langage à prototype possèdant un compilateur ayant de bonne performance à l'exécution. Dans le cadre de cet article, nous ne pouvons pas réaliser une présentation détaillé du langage Lisaac. Le manuel de référence est disponible sur le site du projet Isaac ([http://IsaacOS.loria.fr).](http://IsaacOS.loria.fr).) `**Le langage Lisaac - un langage objet à prototype**` Pour donner une vue globale de Lisaac, notons simplement qu'il est syntaxiquement et sémantiquement proche du langage objet à prototypes Self , ou relativement proche du langage SmallTalk , (ce dernier étant néanmoins un langage à classe). En revanche, contrairement à Self, Lisaac se distingue par un système de type proche du langage Eiffel , avec entre autre la généricité (type paramétrique). `**Caractéristiques de notre petit modèle agent**` Nous allons illustrer les caractéristiques de nos extensions par l'exemple classique de la modélisation d'une fourmillière. `Régles et déclaration d'un agent` Un ensemble de règles doivent être respecter pour définir un agent : **Régle n°1 :** Un prototype représentant un agent se distingue par l'affectation de la mention agent dans le slot category de la section header du Lisaac (voir fig. ligne (1)). **Régle n°2 :** Un agent doit obligatoirement hériter du prototype AGENT directement ou indirectement via l'arbre d'héritage (voir fig. ligne (2)). Notons que le prototype AGENT n'est pas de catégorie agent. Le prototype AGENT implante un ensemble de fonctionnalité générique et nécessaire aux agents. Ce point fait l'objet de la section "Un agent : un prototype toujours actif". De plus, cela nous permet de respecter les règles de typage du langage Lisaac lors de la manipulation des agents. **Régle n°3 :** Un prototype de catégorie agent est obligatoirement un prototype feuille et ne peut donc pas être parent d'un autre prototype. Cela implique l'absence d'un prototype de catégorie agent dans l'arbre d'héritage d'un agent. Cette règle permet une cohérence et une simplification du modèle d'exécution parallèle des agents que nous développons en section exécution. **Régle n°4 :** La déclaration du slot is_in de type agent est obligatoire dans la description du prototype AGENT (voir fig. ligne (3)). Ce slot est utilisé au niveau de la hierarchisation récurssive des SMAs et dans la communication inter-agent. Nous autorisons toutefois son absence pour un seul agent dans le système, la section meta-agent développe la présence de ce slot. section HEADER £spaces£ £/spaces£+ name := FOURMI; £spaces£ £/spaces£- category := AGENT _// (1)_ section INHERIT £spaces£ £/spaces£* parent_fourmi:AGENT; _// (2)_ section PUBLIC £spaces£ £/spaces£- is_in:AGENT := FOURMILLIERE _// (3)_ _Figure 1. Exemple de déclaration de l’agent F O U R M I_ `Définition récursive d'un agent` Une des bases de la définition d'un système multi-agent repose sur la récursivité de la notion : un SMA peut être lui-même un agent d'un autre SMA. Dans notre exemple, chaque organe d'une fourmi est un agent appartenant au SMA définissant l'entité d'une fourmi. Aussi, chaque fourmi peut être considéré comme un agent du SMA représentant la fourmillière. De même, plusieurs fourmillières peuvent définir un SMA englobant l'univers d'application de notre simulation. Le slot is_in imposé par la règle 4 permet d'architecturer les niveaux entre eux. Dans l'exemple de la figure , l'agent fourmi appartient à l'agent ou meta-agent, ou encore SMA fourmilliere. Cette appartenance étant réalisé par un slot classique, elle reste dynamique. Un SMA (ou meta-agent) peut alors diriger et inter-agir en donnant des directives à ces agents de deux manières : * via un message classique entre agents (voir section communication) ; * via un message en _multicast_ en utilisant comme sélection la valeur du slot is_in. L'agent représentant le SMA de l'univers d'application est l'unique agent n'ayant pas de slot is_in. Dans notre exemple, l'ensemble des agents fourmiliere appartiennent au SMA englobé dans l'agent world. Celui-ci étant l'univers d'application, il ne possède pas de slot is_in décrivant son appartenance. `Un agent : un prototype toujours actif ` A la différence d'un objet qui n'est actif que lors d'un envoi de message, un agent doit pouvoir être toujours actif et avoir son propre comportement indépendemment des autres. Ainsi, chaque agent a son propre contexte d'exécution. Le clonage d'un agent à pour conséquence d'obtenir un nouveau contexte d'exécution pour le fonctionnement de celui-ci. La définition de ce clonage particulier est décrit dans le prototype AGENT ; parent imposé par la règle 2 de la déclaration d'un agent. Aussi, pour éviter tout problème d'incohérence des données communes entre deux agents cloné, nous réalisons une duplication récursive de ses données (_deepclone_). Si le programmeur est désireux de partager des données à plusieurs agents, cela est toujours rendu possible par la construction d'un agent contenant ces données. Cette encapsulation permet de gérer de manière fiable la cohérence de ces données lors d'accès multiple à un instant _T_. `Communication inter-agent ` La communication est réalisé par un envoi de message classique de type agent.slot. Si le slot contient du code (méthode ou procédure), deux cas sont possible : * Si l'appelant réclame une réponse, par exemple a := agent.slot, le flot d'exécution de l'appelant est stoppé jusqu'à obtention de cette valeur de retour. * Si l'appelant ne réclame pas de réponse, le message est envoyé, stocké dans une FIFO de l'agent appelé, et l'appelant continu son flot d'exécution. Le message sera traité ultérieurement selon le choix et le comportement de l'agent visé. Au niveau du prototype AGENT, nous avons deux slots particuliers permettant de gérer et de maîtriser la FIFO interne des messages asynchrones : * has_new_message de type boolean permet de savoir si un message est en attente dans la FIFO. * pop_message qui à pour objectif de déclencher l'exécution d'un message en attente dans la FIFO. Si le slot appelé contient une donnée, nous renvoyons directement celle-ci sans passer par la FIFO et sans couper le flot d'exécution de l'agent appelé et l'agent appelant. Les objets passés entre agents (arguments ou valeurs de retour) sont traités selon leurs types de la manière suivante : * Si l'objet est de type Expanded, objet de petite taille, comme un entier, un booléen, un caractère... , l'objet est directement passé d'un agent à l'autre. * Si l'objet est d'un type plus complexe (chaîne de caractère, structure, ...), nous réalisons automatiquement un clonage récursif (_deepclone_) pour éviter les incohérences possible causé par le partage de cet objet. Une gestion plus complexe d'envoi de message de type _mail_ est alors rendu possible par l'utilisation de ces primitives par une librairie standard. `Comportement ` Un agent, intrinsèquement actif, doit décrire son comportement réactif. Celui-ci exprime comment l'agent se comporte à chaque instant et plus exactement quel comportement adopte t-il en fonction de son environnement. Chaque comportement est lié à des conditions de son environnement ou à un état interne. C'est pour cela que nous décrivons le déclenchement d'un comportement à l'aide de clauses satisfaites lors de l'application de celui-ci. Chaque clause implémente le concept de cause à effet : La satisfaction d'une clause, autrement dit d'une cause directement liée à l'agent donne lieu à un effet (le comportement proprement dit). Les clauses se posent sous forme d'une expression booléenne comportant un ensemble de termes et de connecteurs logiques. Dans un langage objet classique, un message ayant un identifiant est à la base du déclenchement d'une action. Ici, nous remplaçons identifiant de message par la clause en question. De ce fait, le déclenchement de l'action (effet) est directement lié à la satisfaction de sa clause. £spaces£ £/spaces£section PUBLIC £spaces£ £/spaces£- (is_hungry) <- £spaces£ £/spaces£( £spaces£ £/spaces£to_eat_action; £spaces£ £/spaces£); Exemple : Si la clause (is_hungry) est vrai, l'agent réalise l'action de manger. Tant que la clause est satisfaite, l'action se répète. Il peut être nécessaire de réaliser une action préalable au comportement répétitif Preface et une action de finalisation de ce comportement Postface. Exemple : £spaces£ £/spaces£section PUBLIC £spaces£ £/spaces£- (is_hungry) <- £spaces£ £/spaces£**Preface** £spaces£ £/spaces£{ £spaces£ £/spaces£to_make_food; £spaces£ £/spaces£} £spaces£ £/spaces£( £spaces£ £/spaces£to_eat_action; £spaces£ £/spaces£) £spaces£ £/spaces£**Postface** £spaces£ £/spaces£{ £spaces£ £/spaces£to_clear_table; £spaces£ £/spaces£}; Exemple : Ici, si la clause (is_hungry) est vrai, l'agent commence par faire à manger to_make_food, puis fait l'action de manger to_eat_action tant que la clause est vrai. Avant de démarrer un autre comportement, l'agent débarrassera la table to_clear_table. Comme l'action répété peut être interrompu à tout moment, le code présent dans la partie Postface permet de rendre la cohérence des données causé par la rupture brutal de l'action. Il est possible que plusieurs clause soit satisfaite à un même instant. Le choix du comportement prioritaire sera réalisé par une force de priorité défini après une clause. £spaces£ £/spaces£section PUBLIC £spaces£ £/spaces£- (is_hungry) **Priority** 5 <- £spaces£ £/spaces£( £spaces£ £/spaces£to_eat_action; £spaces£ £/spaces£); £spaces£ £/spaces£- (has_enemy) **Priority** 10 <- £spaces£ £/spaces£( £spaces£ £/spaces£to_beat; £spaces£ £/spaces£); Exemple : Si l'agent a un ennemi, il fait l'action de se battre, même si il a faim. Notons que la priorité par défaut est de 0. En cas d'égalité des priorités, l'ordre de déclaration des comportements rentre en jeu. `Le prototype AGENT` Nous avons décrit dans les sections précédente à certain nombre de fonctionnalité présente dans ce prototype. Ici, nous les rappelons rapidement en ajoutant certaines notions qui nous paraisse important. section HEADER £spaces£ £/spaces£+ **name**:= AGENT; £spaces£ £/spaces£- **category** := MICRO; section £spaces£ £/spaces£- **clone**:SELF <- /* code system */ £spaces£ £/spaces£_// Nouvelle définition du slot `clone' (deep-clone)_ £spaces£ £/spaces£_// Avec création d'un nouveau contexte d'exécution_ £spaces£ £/spaces£- **has_new_message**:BOOLEAN <- /* code system */ £spaces£ £/spaces£_// Vrai, si un message est en attente dans la FIFO_ £spaces£ £/spaces£- **pop_message** <- /* code system */ £spaces£ £/spaces£_// Retire et exécute un message de la FIFO_ £spaces£ £/spaces£- (has_new_message) **Priority** 0 <- £spaces£ £/spaces£_// Comportement par défaut: Execution au plus tot d'un message en attente_ £spaces£ £/spaces£( £spaces£ £/spaces£pop_message; £spaces£ £/spaces£); £spaces£ £/spaces£- **time**:UINTEGER <- /* code system */ £spaces£ £/spaces£_// Renvoi l'age de l'agent en milisecond_ £spaces£ £/spaces£- **timein**:UINTEGER; £spaces£ £/spaces£_// Variable contenant un temps, nécessaire au calcul d'une durée._ £spaces£ £/spaces£ £spaces£ £/spaces£- **timeout** limit_time:UINTEGER :BOOLEAN <- £spaces£ £/spaces£_// Calcul la durée écoulé entre `time' et `timein'._ £spaces£ £/spaces£_// Renvoi Vrai, si cette durée est inférieur ou égal à la_ £spaces£ £/spaces£_// valeur `limit_time' ou si `timein' est égal à 0._ £spaces£ £/spaces£( £spaces£ £/spaces£(timein = 0) || {(time - timein) <= limit_time} £spaces£ £/spaces£); `Exemples de comportements attendus ` Si nous voulons qu'un comportement soit interrompu pour répondre à un message, nous pouvons utiliser la forme suivante : - (stat = 0) <- _// current_behaviour_ ( _// Code of behaviour_ ); Par défaut, la priorité d'un comportement est 0, le comportement par défaut défini dans le prototype AGENT sera prioritaire (car déclaré de priorité 0, mais avant notre comportement). Notre comportement reprendra automatiquement son exécution après le traitement du message (au passage de has_new_message = FALSE. Si nous ne désirons pas interrompre un comportement par un message, nous pouvons utiliser la forme suivante : - (stat = 0) **Priority** 1 <- _// current_behaviour_ ( _// Code of behaviour_ ); La priorité est supérieur au traitement d'un message. Si nous voulons qu'un comportement de priorité supérieur à 0 soit néanmoins interrompu pour répondre à un message, nous pouvons utiliser la forme suivante : £spaces£ £/spaces£- ((stat = 0) & (! has_new_message)) **Priority** 1 <- £spaces£ £/spaces£_// current_behaviour_ £spaces£ £/spaces£( £spaces£ £/spaces£_// Code of behaviour_ £spaces£ £/spaces£) £spaces£ £/spaces£**Postface** £spaces£ £/spaces£{ £spaces£ £/spaces£pop_message; £spaces£ £/spaces£}; Un système multi-agent doit être réactif, et se conceptualise en temps réel. Le programmeur doit avoir la possibilité de conditionner l'exécution d'un comportement avec une limite de temps. Pour limiter l'exécution d'un comportement _A_ à 30 millisecondes pour ensuite passer à un comportement _B_, nous pouvons utiliser la forme suivante : £spaces£ £/spaces£- ((stat = 0) & (timeout 30)) <- £spaces£ £/spaces£_// Current behaviour A_ £spaces£ £/spaces£**Preface** £spaces£ £/spaces£{ £spaces£ £/spaces£timein := time; £spaces£ £/spaces£} £spaces£ £/spaces£( £spaces£ £/spaces£_// Code of behaviour A_ £spaces£ £/spaces£) £spaces£ £/spaces£**Postface** £spaces£ £/spaces£{ £spaces£ £/spaces£stat := 1; £spaces£ £/spaces£timein := 0; £spaces£ £/spaces£}; £spaces£ £/spaces£- (stat = 1) <- £spaces£ £/spaces£_// behaviour B_ £spaces£ £/spaces£( £spaces£ £/spaces£_// Code of behaviour B_ £spaces£ £/spaces£) Si nous voulons changer de comportement de manière synchrone à un nouvelle état d'un autre agent: £spaces£ £/spaces£- ((stat = 0) & (other_agent.stat != 1)) <- £spaces£ £/spaces£_// current_behaviour_ £spaces£ £/spaces£( £spaces£ £/spaces£_// Code of behaviour_ £spaces£ £/spaces£) £spaces£ £/spaces£**Postface** £spaces£ £/spaces£{ £spaces£ £/spaces£stat := 1; £spaces£ £/spaces£}; £spaces£ £/spaces£- (stat = 1) <- £spaces£ £/spaces£_// New behaviour_ £spaces£ £/spaces£( £spaces£ £/spaces£_// Code of new behaviour_ £spaces£ £/spaces£); _**Extraction de données **_ Les systèmes multi agents supposent une communication accrue, en particulier les agents complexes et cognitifs. Une modélisation complexe nécessite une bonne connaissance de l'environnement extérieur, en particulier des connaissances complexes sur les propriétés d'agent et objets extérieur. Dans les langages classiques, le programmeur est obligé de parcourir inlassablement des collections pour y trouver les données qu'il cherche. Dans un langage agent, c'est la communication qui pallie à ce manque. Nous avons cherché un à définir un mécanisme utilisable par les agents et par les objets. C'est pourquoi le modèle Lisaac agent intègre un mécanisme d'extraction des données inspiré entre autre de SQL, il s'agit d'envoyer des requêtes permettant de filtrer des données à partir d'une ou plusieurs collections d'objets, ainsi que de déterminer une liste d'objets/agent répondant à certains critères. On peut lister les fourmis ouvrières, s'occupant des couvains L'objet "ensemble" est un objet dynamique - position : NUMERIC; - etat : SEMANTIC; (position,etat) := list pos,etat where agent.type = OUVRIERE and agent.current_behavior = rentrer_a_la_fourmilliere; Lire à ce sujet la publication "QUEROM : AN OBJECT-ORIENTED MODEL TO REWRITING QUERY USING VIEWS" qui propose un très bon modèle. [http://csl.ensm-douai.fr/seriai/uploads/11/SERIAI_ICIES_CAME(...)](http://csl.ensm-douai.fr/seriai/uploads/11/SERIAI_ICIES_CAMERA.pdf) `**Conclusion**` Le modèle "Lisaac Agent" se veut une synthèse pragmatique entre un langage à objet à prototype classique et un langage permettant de implémenter des systèmes multi-agent réactifs. Nous proposons un langage de haut niveau qui se veut simple, intuitif tout en restant puissant et polyvalent. Designer des agent cognitifs y est par contre beaucoup plus difficile, ce langage se positionne clairement dans le domaine d'agent réactifs, car nous le percevons comme le prolongement naturel de l'approche objet. Néanmoins, le programmeur pourra développer des systèmes multi-agents capable de manifester des comportements cognitifs grâce à l'émergence de comportement intelligents au sein de SMA réactifs. Ce modèle permet de constater que mise à part l'intégration du paraléllisme automatique dans le langage, un langage orienté multi-agent est très proche d'un langage objet classique. Note : Les agents doivent "matériellement" considérés comme des threads. Voilà, la discussion est ouverte. Je m'attend à des résistances conservatrices, comme d'habitude, mais ayez bien à l'esprit, qu'il s'agit pour moi de raisonner à 10-15 ans devant nous. On ne pourra indéfiniment programmer en Java/Lisp et consort. Il s'agit aussi d'imaginer des logiciels diminuant intrinsèquement le nombre de bugs, et ne demandant pas des connaissances mathématiques poussées qui ne sont à la porté que d'une minorité (je dis ça pour ceux qui me répondront LISP ! Caml ! Oz ! Haskel !). Il s'agit de libérer la puissance de l'intuition humaine. Mes amis, soyez créatifs et visionnaires !

AltStyle によって変換されたページ (->オリジナル) /