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.