Quand je vois celà : section HEADER
+ name := FOURMI;
- category := AGENT // (1)
section INHERIT
* parent_fourmi:AGENT; // (2)
section PUBLIC
- is_in:AGENT := FOURMILLIERE // (3)
et les différents méccanismes mis en place dans ton langage je me pose une question, as-tu jamais lu un livre sur les fondements de la programation paradigmatique ou multiparadigmatique ?
Par exemple ton déclarateur is_in pour décrire le slot à la construction de l'agent m'a l'air très casse gueule et peu intuitif.
De plus la variation des comportements me parait également bancale.
Par exemple pour le passage
- ((stat = 0) & (timeout 30)) <-
// Current behaviour A
Preface
{
timein := time;
}
(
// Code of behaviour A
)
Postface
{
stat := 1;
timein := 0;
};
- (stat = 1) <-
// behaviour B
(
// Code of behaviour B
)
J'ai peur. Tout d'abord quid de la gestion des popmessages dans ce cas là ? Faut-il les prendre en compte à la main dans dans le code comportemental ou sont-ils gérés en time sharing par le thread en parallèle ? Sont-ils gérés par interruption système ? Sont-ils dans une boucle invisible ? Dans les deux premiers cas quid de la fiabilité d'éxécution et dans le dernier cas quid de la garantie temps-réel ? Mêmes questions pour le timeout(30)
Ensuite pour les code comportementaux la notion de variable de décision me parait étrange dans un paradigme qui se veut porche du raisonnement humain
Pourquoi ne pas créer des slots comportementaux, pendant fonctionnels des slots agents.
Faire un truc du genre
--------------------------------------------------------
section BSLOT_HEADER
+ name := BEHAVIOUR_A;
- category := BSLOT
section RELATED_TO
* parent_fourmi:AGENT; // (2)
section ACTIVE
{//code du comportement a si actif}
section STOP
{//code du comportement a avant de passer la main}
section RESUME
{//code du comportement a en reprise de main}
section SLEEP
{//code de comportement a du programme en attente (message apr exemple)}
------------------------------------------------------------
Le code précédent deviendrait :
-------------------------------------------------
- (timeout 30)) <-
// Current behaviour A
Preface
{
timein := time;
}
(
is_active(BEHAVIOUR_A)
)
Postface
{
stop(BEHAVIOUR_A)
};
Preface
{
//condition d'arret du comportement B
}
// behaviour B
(
// Code of behaviour B
)
Postface
{
//cleaning
}
resume(BEHAVIOUR_A)
----------------------
Celà aurait a) l'avantage de ne pas se trimballer de variables (qui vont forcément géner sur ce genre de paradigme de programmation) et b) de pouvoir garder la main sur un comportement que l'on a stoppé brutalement pour des impératifs temps réel.
Mais bon il se peut que ce soit difficile/impossible à réaliser.
(N.B / il se peut qu'il y ait des monstruosité dans le pseudo-code écrit, je n'ai jamais fait de LISSAC dans ma vie, je me suis juste inspiré des exemples donnés. )
# C'est pas mal du tout ton truc. Mais j'ai un gros doute...
Posté par Jerome Herman . En réponse au journal Le langage de mes rêves. Évalué à 10.
section HEADER
+ name := FOURMI;
- category := AGENT // (1)
section INHERIT
* parent_fourmi:AGENT; // (2)
section PUBLIC
- is_in:AGENT := FOURMILLIERE // (3)
et les différents méccanismes mis en place dans ton langage je me pose une question, as-tu jamais lu un livre sur les fondements de la programation paradigmatique ou multiparadigmatique ?
Par exemple ton déclarateur is_in pour décrire le slot à la construction de l'agent m'a l'air très casse gueule et peu intuitif.
De plus la variation des comportements me parait également bancale.
Par exemple pour le passage
- ((stat = 0) & (timeout 30)) <-
// Current behaviour A
Preface
{
timein := time;
}
(
// Code of behaviour A
)
Postface
{
stat := 1;
timein := 0;
};
- (stat = 1) <-
// behaviour B
(
// Code of behaviour B
)
J'ai peur. Tout d'abord quid de la gestion des popmessages dans ce cas là ? Faut-il les prendre en compte à la main dans dans le code comportemental ou sont-ils gérés en time sharing par le thread en parallèle ? Sont-ils gérés par interruption système ? Sont-ils dans une boucle invisible ? Dans les deux premiers cas quid de la fiabilité d'éxécution et dans le dernier cas quid de la garantie temps-réel ? Mêmes questions pour le timeout(30)
Ensuite pour les code comportementaux la notion de variable de décision me parait étrange dans un paradigme qui se veut porche du raisonnement humain
Pourquoi ne pas créer des slots comportementaux, pendant fonctionnels des slots agents.
Faire un truc du genre
--------------------------------------------------------
section BSLOT_HEADER
+ name := BEHAVIOUR_A;
- category := BSLOT
section RELATED_TO
* parent_fourmi:AGENT; // (2)
section ACTIVE
{//code du comportement a si actif}
section STOP
{//code du comportement a avant de passer la main}
section RESUME
{//code du comportement a en reprise de main}
section SLEEP
{//code de comportement a du programme en attente (message apr exemple)}
------------------------------------------------------------
Le code précédent deviendrait :
-------------------------------------------------
- (timeout 30)) <-
// Current behaviour A
Preface
{
timein := time;
}
(
is_active(BEHAVIOUR_A)
)
Postface
{
stop(BEHAVIOUR_A)
};
Preface
{
//condition d'arret du comportement B
}
// behaviour B
(
// Code of behaviour B
)
Postface
{
//cleaning
}
resume(BEHAVIOUR_A)
----------------------
Celà aurait a) l'avantage de ne pas se trimballer de variables (qui vont forcément géner sur ce genre de paradigme de programmation) et b) de pouvoir garder la main sur un comportement que l'on a stoppé brutalement pour des impératifs temps réel.
Mais bon il se peut que ce soit difficile/impossible à réaliser.
(N.B / il se peut qu'il y ait des monstruosité dans le pseudo-code écrit, je n'ai jamais fait de LISSAC dans ma vie, je me suis juste inspiré des exemples donnés. )