Discussion :

[Montaigne]

Bonjour, j'implémente en ce moment une machine à état hiérarchique en caml. Une machine à état hiérarchique est une machine à état donc chaque état peut contenir une machine à état.
Cette machine à état permet de contrôler le comportement d'un agent.

Je tente de réaliser cela avec un mix d'objet et de type somme en caml.
J'ai donc une classe agent et une classe state qui elle représente mon état.
State a un état parent (celui qui le contient), un état enfant (la machine à état qu'il contient et l'état de "départ" auquel il est lié. On y a diverses actions qui feront l'objet de la question 2.
Les transitions permettent de construire un arbre composant des conditions et des évènements.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
class agent = 
object
  val mutable startState = new state;
end
 
 
and
 
 
 transition = Condition of (agent -> bool) | 
Event of (agent -> bool) |
ConditionOr of  (agent -> bool) |
ConditionAnd  of  (agent -> bool) |
ConditionXor of   (agent -> bool) |
ConditionNor of   (agent -> bool)
 
and 
 stateOuRien = State of state | None
 
 
and
  state = 
object
 val mutable parentstate = State( new state);
 val mutable substate = State( new state);
 val mutable transitions  = [];
 val mutable begin_action = (function a-> a#startState = new state);
  val mutable action  = (function a-> a#startState = new state);
  val mutable end_action  = (function a-> a#startState = new state);
end;;

Première question : J'ai une belle syntaxe error.. Le problème est que mes définitions de type sont tous interdépendantes mais que je ne parviens pas à faire en sorte de lui faire manger tout cela d'un seul coup.
Y a t-il une astuce ?

Seconde question : Je suis en train de lui imposer une notion que je pense un peu limite. En effet, mon
val mutable end_action = (function a-> a#startState = new state);
correspond au type block qu'on trouve dans les langages objets avancés (Smalltalk, Ruby, Lisaac, ...). En gros, c'est une propriétés de ma classe dans laquelle j'aimerai affecter/changer une fonction quand bon me semble.

Question subsidiaire : j'ai du mal à lui faire comprendre quel type je veux exactement pour mes propriétés, s'il y avait un moyen de simplement lui définir un type (propriétés : type ) comme dans les langages objets classique, je suis preneur..

Merci !

[TropMDR]

Salut

La première chose que je dirais : es-tu certain d'avoir besoin d'objet ? Parce que les objets en caml, c'est ultra puissant, mais ça fait aussi sévèrement mal au crâne.

Par exemple toutes tes classes n'ont que des variables. Or seul les méthodes sont accessibles de l'extérieur en caml. Donc elles sont moralement inutiles.

Ensuite je ne pense pas que tu puisses définir des classes récursivement avec des types

Est ce que tu es vraiment sûr que tu as besoin soit d'héritage, soit de sous typage ? Dans le cas contraire, un type "classique" serait sans doute bien plus utile...


Pour finir, une question de style:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
type foo =
  | bar
  | baz

avec les pipes en début de lignes

[Montaigne]

Salut

La première chose que je dirais : es-tu certain d'avoir besoin d'objet ? Parce que les objets en caml, c'est ultra puissant, mais ça fait aussi sévèrement mal au crâne.

Par exemple toutes tes classes n'ont que des variables. Or seul les méthodes sont accessibles de l'extérieur en caml. Donc elles sont moralement inutiles.

utiliser des classes m'arrangerai car j'ai effectivement besoin de méthodes.
J'aimerai éviter une vision "procédurale" avec des procédures/fonctions qui travaille sur mes records.

Ensuite je ne pense pas que tu puisses définir des classes récursivement avec des types

Est ce que tu es vraiment sûr que tu as besoin soit d'héritage, soit de sous typage ? Dans le cas contraire, un type "classique" serait sans doute bien plus utile...

Effectivement, je n'ai pas besoin d'héritage, mais j'ai besoin de méthodes, pour les raisons expliqués plus haut.
Surtout que le tout va devenir paramétrique

Pour finir, une question de style:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
type foo =
  | bar
  | baz

avec les pipes en début de lignes

J'y veillerai :-)

Une idée pour mes types blocks ?

[gasche]

Tu peux utiliser un module récursif pour nouer le nœud entre types et classes. C'est un peu compliqué et, si tu es débutant, le mieux est d'éviter ce genre de choses.

On peut aussi "casser le cycle" en paramétrant les types classes, avant de les instancier.

Je te conseille d'abandonner l'idée de faire de la POO pour l'instant. D'après ce qu'on voit sur ce topic, ta connaissance de la POO n'est que superficielle, et je pense que tu cours après de belles idées sur le papier que tu ne maîtrises pas forcément. Dans ce contexte, pas la peine de faire des efforts pour sauvegarder le style POO (si tu avais fait de la POO pendant 10 ans auparavant, je ne dis pas...).

Essaie de faire les choses avec des types sommes, des tuples et des records. Ça te paraîtra peut-être bizarre au début, mais tu te rendras compte que c'est aussi propre et modulaire. D'ailleurs tu peux très bien mettre des fonctions dans les enregistrements si tu en as envie, et c'est même nettement plus propre et modulaire que de la POO bourrée de "val mutable ..".

« à Rome, fais comme les Romains »

Une fois qu'on connaît bien OCaml, on peut s'intéresser à sa couche objet. C'est intéressant, mais ça demande des connaissances du langage, ou au moins du typage des idiomes objets. Quand on est débutant, ce n'est pas une bonne idée.

[Montaigne]

Tu peux utiliser un module récursif pour nouer le nœud entre types et classes. C'est un peu compliqué et, si tu es débutant, le mieux est d'éviter ce genre de choses.

On peut aussi "casser le cycle" en paramétrant les types par les définitions de classe, avant de les instancier.

Je te conseille d'abandonner l'idée de faire de la POO pour l'instant. D'après ce qu'on voit sur ce topic, ta connaissance de la POO n'est que superficielle, et je pense que tu cours après de belles idées sur le papier que tu ne maîtrises pas forcément. Dans ce contexte, pas la peine de faire des efforts pour sauvegarder le style POO (si tu avais fait de la POO pendant 10 ans auparavant, je ne dis pas...).

Alors je t'arrête tout de suite, je connais très bien la POO depuis une dizaine d'année. J'ai aussi conçu une partie des spécifications du langage Lisaac, qui est le premier langage à prototype compilé. Ce langage est tellement objet que même if then else est en lib (if est un message de True et False qui héritent de Boolean, comme en Smalltalk).
Et je suis pas sûr que tu connaisse le prototype, c'est bien plus puissant que les classes.
J'ai beaucoup étudié la compilation de ces langages (je connais bien Dominique Colnet, l'auteur de SmartEiffel et Benoit Sonntag l'auteur de Lisaac), que j'ai appris directement de ces 2 chercheurs qui l'implémentent (et pour avoir inlassablement relus leur papiers avant l'envoi aux reviewers).
Le code que j'ai mis ici est simplifié à l'extrême pour ne pas vous embrouiller. C'est un problème de typage, donc j'ai limité le code à ce problème.

Ce code est en fait une copie adapté en caml d'un code que j'ai écris en lisaac, mais qui pose quelques problème au compilateur dans certains cas (j'ai reussi à débugguer le compilateur jusqu'à un certain stade, mais j'ai abandonné).
Je n'ai pas mis les méthodes, c'est volontaire, car c'est inutile pour faire comprendre mon problème.

Et pour le reste, parce que tu as vraiment l'air de penser que je suis un imbécile, ça fait 20 ans que je code, dans à peu près tous les langages et la plupart des paradigmes.

Essaie de faire les choses avec des types sommes, des tuples et des records. Ça te paraîtra peut-être bizarre au début, mais tu te rendras compte que c'est aussi propre et modulaire. D'ailleurs tu peux très bien mettre des fonctions dans les enregistrements si tu en as envie, et c'est même nettement plus propre et modulaire que de la POO bourrée de "val mutable ..".

« à Rome, fais comme les Romains »

Une fois qu'on connaît bien OCaml, on peut s'intéresser à sa couche objet. C'est intéressant, mais ça demande des connaissances du langage, ou au moins du typage des idiomes objets. Quand on est débutant, ce n'est pas une bonne idée.

Ca fait 10 ans que je fais du caml, en pointillé, certes, mais 10 ans quand même, et j'ai conçu des typages plus couillus que ça.

Merci pour la condescendance.

Va pour les record si je peux mettre des fonctions dedans, ça ressemblera à de l'objet, et en plus s'approche du prototype, ce qui m'arrange, vu que je déteste l'objet à classe.

Cette solution me parait intéressante :
- a mon avis l'objet en ocaml doit être mal compilé (probablement plein de VFT (Virtual Function Table : voir http://en.wikipedia.org/wiki/Late_binding ) qui trainent, et j'ai peur que ce soit donc très lent.
- Je n'ai pas besoin d'héritage dans mon cas, bien que j'aimerai bien que mon objet hérite de agent<T>, mais à la limite, je pourrai faire une colle avec mon record.

Si je prend ce modèle
Est-ce que je peux facilement avoir mon type block, à savoir ma fonction dans un mutable ?

[TropMDR]

Le code que j'ai mis ici est simplifié à l'extrême pour ne pas vous embrouiller. C'est un problème de typage, donc j'ai limité le code à ce problème.

Sauf qu'en fait non, puisqu'en caml, les variables d'instance ne font *pas* partie du type des objets, mais uniquement les méthodes.

Ce code est en fait une copie adapté en caml d'un code que j'ai écris en lisaac, mais qui pose quelques problème au compilateur dans certains cas (j'ai reussi à débugguer le compilateur jusqu'à un certain stade, mais j'ai abandonné).

Lisaac a l'air d'être un langage purement objet. Ce n'est pas le cas de caml. Donc il est aussi possible que juste "traduire" la syntaxe ne soit pas une super idée dans ce cas. Il serait bon d'envisager de changer de style aussi, puisque les deux langages sont fondamentalement différents. Ensuite je ne connais pas le système de type de lisaac, mais celui de caml, surtout pour la partie objet, est assez déroutant. Par exemple il n'y a aucun lien entre héritage et sous typage. (on peut être de même type en étant créé par de façon totalement différente, et une sous classe peut ne pas être sous type de sa classe parente). Et les "contrainte" sont assez chevelues.

Ca fait 10 ans que je fais du caml, en pointillé, certes, mais 10 ans quand même, et j'ai conçu des typages plus couillus que ça.

Avoue que quand on voit ta maitrise de la syntaxe caml, et que par exemple tu définies un type "stateOuRien" qui n'est rien que "state option", ou encore que tu tentes d'affecter un attribut d'un objet, il est assez naturel de penser que tu ne connais globalement pas le langage.

Cette solution me parait intéressante :
- a mon avis l'objet en ocaml doit être mal compilé (probablement plein de VFT (Virtual Function Table : voir http://en.wikipedia.org/wiki/Late_binding ) qui trainent, et j'ai peur que ce soit donc très lent.

Oui, tout est à coup de vtables, et non, ce n'est clairement pas la partie la plus optimisés du langage.

Maintenant, ce qui serait plus simple pour nous, ce serait que tu nous expliques ce que tu veux faire, plutôt que nous donner une "solution" complètement cassée qu'on devrait comprendre et modifier.

[Montaigne]

Sauf qu'en fait non, puisqu'en caml, les variables d'instance ne font *pas* partie du type des objets, mais uniquement les méthodes.

C'est effectivement, surprenant, j'en avais entendu parler, mais j'ai jamais creusé la question

Lisaac a l'air d'être un langage purement objet. Ce n'est pas le cas de caml. Donc il est aussi possible que juste "traduire" la syntaxe ne soit pas une super idée dans ce cas. Il serait bon d'envisager de changer de style aussi, puisque les deux langages sont fondamentalement différents.

J'ai énormément modifié la structure tout de même, car dans la version lisaac, tout était en objet et en types blocks. Je n'ai gardé que 2 objets, mis les transitions en type somme, et je pense que je mettrai le reste en module, car si le pattern singleton est trivial en prototype, il est pénible en classe,et de toutes façon pas possible en ocaml, car il n'y a pas de variable "statique" (comme en javouille).

Ensuite je ne connais pas le système de type de lisaac, mais celui de caml, surtout pour la partie objet, est assez déroutant. Par exemple il n'y a aucun lien entre héritage et sous typage. (on peut être de même type en étant créé par de façon totalement différente, et une sous classe peut ne pas être sous type de sa classe parente). Et les "contrainte" sont assez chevelues.

J'en avais aussi vaguement entendu parlé, et c'est pas idiot. Il est des fois utile de séparer les deux. L'intérêt majeur de l'héritage, c'est l'algorithme de lookup, reste à voir si la recherche dans l'arbre se fait en largeur comme dans la plupart des langages à classe, ou en profondeur.

Avoue que quand on voit ta maitrise de la syntaxe caml, et que par exemple tu définies un type "stateOuRien" qui n'est rien que "state option", ou encore que tu tentes d'affecter un attribut d'un objet, il est assez naturel de penser que tu ne connais globalement pas le langage.

C'est clair, que c'est un langage dans lequel je pond 2000 lignes tous les 3 ans depuis 10 ans.
j'ai surtout une maitrise venant de caml light (que j'ai appris à la fac, comme la plupart des gens).
Disons que je suis assez à l'aise avec la partie type somme/type produit de caml. Après je connais beaucoup moins le folklore et les subtilités du Objective caml.
Mais je me sens pas trop débutant (je l'ai été) en caml niveau typage, pour le reste oui, c'est assez vrai.

Oui, tout est à coup de vtables, et non, ce n'est clairement pas la partie la plus optimisés du langage.

C'est Dominique Colnet qui a inventé la résolution de la liaison dynamique, en utilisant des tables d'appels dichotomiques.
Malheureusement, SmartEiffel et Lisaac ont l'air d'être les deux seuls langages à implémenter cela.

Maintenant, ce qui serait plus simple pour nous, ce serait que tu nous expliques ce que tu veux faire, plutôt que nous donner une "solution" complètement cassée qu'on devrait comprendre et modifier.

Alors, je l'ai un peu décrit en une phrase, je vais essayer d'être plus clair.
Je me recite d'abord

Une machine à état hiérarchique (HFSM en anglais) est une machine à état donc chaque état peut contenir une machine à état.
Cette machine à état permet de contrôler le comportement d'un agent.

Un bon schéma vaut bien mieux qu'un long discours dont le papier original est ici (tiens je viens de faire le lien que Harel, c'est le type qui bosse sur le scenario based programming, belle progression intellectuelle, mais bref).

En gros c'est une machine à état classique avec des états et des transitions.
Les transitions entre un état A1 et A2 et un autre se font lorsque la machine est dans l'état A1 et que la condition de transition vers A2 est valide.
Pour mes besoins "temps réel", je rajoute la notion d'évènement qui peut être mixé avec la condition selon la grammaire que j'ai défini dans le type transition. En gros c'est une composition logique (avec op binaires classiques) entre plusieurs conditions et plusieurs events (potentiellement).

Le fait que cette machine à état soit hiérarchique rajoute pas mal de chose : on doit toujours chercher l'état le plus "profond" pour l'exécuter, et chercher les transitions du père de plus haut niveau pour savoir si l'on doit changer d'état, et redescendre vers son fils appelant.

Donc voilà. Le but est d'avoir une lib qui me permette de définir mes HFSM de manière déclarative.
En lisaac, c'était cool, ça s'écrivait bien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
 life := STATE(AGENTTESTER).create "Life" action { x:AGENTTESTER; "SMA englobant".println;};
etat1 :=  STATE(AGENTTESTER).create "Cycle 1" begin_action { x:AGENTTESTER;
      "Entrée Etat 1\n".print;
    } action { x:AGENTTESTER;
      curetat := 1;
    } end_action { x:AGENTTESTER;
      "Sortie Etat 1!\n".print;
    };
 etat1.to etat2 if { x:AGENTTESTER ; curetat=1};
//Et pour définir un sous FSM :
 etat2.has life;

Au fait, j'ai résolu mon pb !!
Une bidouille que j'utilisais il y a 5 ans : je définis d'abord une classe agent vide, je l'utilise et je la redéfinis. J'avance comme ça incrémentalement jusqu'à redéfinir tout proprement, en "bootstrappant".
On verra si ça marchera à la longue, dans la négative, je rezieuterais tes pistes pour les travailler.

Mais promis, je vais y aller molo sur l'objet en ocaml.

Merci en tout cas !

[gasche]

Montaigne > je suis désolé si je t'ai vexé avec mon ton trop énervé. Mea culpa. Je t'ai pris pour un débutant, certes (il faut dire, vu le code..), mais pas pour un imbécile. D'ailleurs, les deux premiers paragraphes de mon message proposaient deux solutions différentes (modules récursifs et paramétrisation) à ton problème, mais peu développées car je pense que tu aurais plutôt intérêt de toute façon à faire les choses différemment, sans objet.

Ce que tu fais de façon "déclarative" à coup d'effets de bords en Lisaac, tu pourrais sans doute le faire plus proprement, avec beaucoup moins de mutations, en Caml. Je te conseille donc de minimiser au maximum ton emploi des références et des champs mutables, le temps d'une cure de désintoxication.

[Montaigne]

Et j'ai réagi stupidement aussi, c'est un peu ridicule avec le recul.
Disons qu'avec la pratique, j'ai appris que sur un forum, pour pas embrouiller le lecteur, il faut essayer de ne laisser à voir que le strict nécessaire.
Et de plus j'avais vraiment écrit le code comme ça, car je voyais bien que mon problème était de lui faire avaler le système de type. Une fois que les "coques" passent, je peux enrichir le contenus.

Bien que ma bidouille à l'air de fonctionner, je sais pas comment je vais m'y mettre.
Mais de toutes façon, je vais vraiment potasser le ocaml, c'est le seul langage suportable à mes yeux avec lisaac, et comme le compilateur Lisaac n'est pas assez au point pour lui faire avaler tous les trucs super haut niveau que je lui demande, reste caml :-)

Donc, je vais m'y mettre, en me convertissant à la philosophie caml/fonctionnelle, comme tu me le proposes judicieusement :-)

Montaigne > je suis désolé si je t'ai vexé avec mon ton trop énervé. Mea culpa. Je t'ai pris pour un débutant, certes (il faut dire, vu le code..), mais pas pour un imbécile. D'ailleurs, les deux premiers paragraphes de mon message proposaient deux solutions différentes (modules récursifs et paramétrisation) à ton problème, mais peu développées car je pense que tu aurais plutôt intérêt de toute façon à faire les choses différemment, sans objet.

Ce que tu fais de façon "déclarative" à coup d'effets de bords en Lisaac, tu pourrais sans doute le faire plus proprement, avec beaucoup moins de mutations, en Caml. Je te conseille donc de minimiser au maximum ton emploi des références et des champs mutables, le temps d'une cure de désintoxication.

[SpiceGuid]

Deux choses.

1. Tu peux demander un statut membre VIP, ça t'éviterait d'être pris à tort pour un programmeur débutant.

2. Pour ce qui est de ton problème voici la manière qui perturbe le moins ton design initial (bon ou pas bon je n'en discuterai pas avec un potentiel membre VIP)

Code OCaml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
class agent = 
object
  val mutable startState = (object end);
end 

type transition =
  | Condition of (agent -> bool)
  | Event of (agent -> bool)
  | ConditionOr of  (agent -> bool)
  | ConditionAnd of (agent -> bool)
  | ConditionXor of (agent -> bool)
  | ConditionNor of (agent -> bool)

type aState =
  < >  
and stateOuRien =
  State of aState | None 
    
class state = 
object
  val mutable parentstate = State( new state);
  val mutable substate = State( new state);
  val mutable transitions : transition list = [];
  val mutable begin_action = (function a-> a#startState = new state);
  val mutable action = (function a-> a#startState = new state);
  val mutable end_action = (function a-> a#startState = new state);
end

Inconvénient: tu déclares deux types d'état, tu dois faire en sorte qu'ils restent égaux en ajoutant des méthodes dans aState lorsque nécessaire.

[TropMDR]

Amusant, tu as les même réponses sur la mailing liste caml qu'ici "tu peux avec un module récursif, mais c'est lourd, essaye plutôt de te passer des objets"...

[gorgonite]

sans doute parce que la POO est universellement décriée par la communauté OCaml... qui préfère modéliser plus simplement, pour un résultat au moins équivalent