5. Évolution de l'API imposée au cours du projet
Au cours des 2 mois d'implémentation, quelques modifications sont survenues dans l'API senior comme la disparition des instructions freezable,link... En revanche la nouvelle version s'est également enrichit de nouvelles instructions, et a notamment tirée profit d'une intégration avec le langage Scheme encore un peu plus étroite.
5.1. Support des variables locales
par exemple l'ajout d'instruction let&, let*& et letrec&. Ces nouvelles instructions permettent sans aucun doute une facilité de programmation accrue, ainsi qu'une organisation encore plus fine du code réactif que l'on souhaite implémenter.
5.2. Lambdas réactives
Le langage s'est aussi vu rajouter des instructions simulant des sortes de lambda réactives, avec le support du funcall& et du apply&.
L'instruction apply& est strictement identique en terme de sémantique que le apply de Scheme. Une liste d'arguments à appliquer à la lambda lui est passée en paramètre, ainsi que la lambda à exécuter.
L'instruction funcall& est à peu près la même, à ceci près que les arguments à passer à la fonctions sont ici donnés un par un.
Ces deux instructions ont complètement modifié la manière d'écrire des comportements et de les mélanger entre eux. La chose est devenue beaucoup plus simple à écrire qu'en Senior 1.0 et est sans doute l'une des meilleurs surprise apportées par ce changement de version.
5.3. Communication avec la machine
Senior supporte maintenant la possibilité de communiquer simplement depuis l'exterieur vers la machine, grâce à l'ajout de l'instruction (generate-in-the-machine& 'ev val). Elle a le même effet que l'instruction generate&, qui elle s'execute depuis l'intérieur de la machine. En revanche, cette instruction rend certaines choses très simple, comme par exemple la communication à la machine du fait que l'utilisateur a tapé une touche.
Il est dommage que l'on ne puisse pas communiquer aussi facilement dans l'autre sens, à savoir detecter qu'un évenement s'est produit à l'intérieur de la machine à un moment donné. Mais cela repose sur la manière de diffuser les évenements, et rajouter cette fonctionnalité aurait surement contrarié la sémantique de Senior.
5.4. Les problèmes d'implémentation de funcall - le clone
L'un des points les plus intéressant dans l'évolution de Senior est le funcall&.
(define *l* '(1))
(define (move o)
(atom& (print o)))
(define *m* (machine& (funcall move *l*)))
(set-car! *l* 2)
(react& *m*)
bash$> (1) |
Ce résultat peut paraître surprenant, car l'implémentation initiale du funcall& dans Senior 2.0 partait du principe que l'objet Scheme qu'on voulait passer en paramètre d'un lambda réactive devait être cloné, puis c'est son clone qui devait être passé. Cela n'était pas dû à des contraintes d'implémentation, mais plutôt à un choix sémantique de la part du concepteur de Senior.
Hors, ce phénomène a posé des problèmes d'implémentations directe lors de l'écriture des comportements réactifs du jeu. Etant en contacts constant avec le développeur de Senior 2.0 Julien Demaria, nous avons pu dialoguer ouvertement de ce problème et la version finale de Senior à finalement été modifiée pour changer de sémantique, et suivre nos besoins.
 | Ce point montre bien que ce projet a finalement été important, en ce sens qu'il a permis de répondre à des problèmes qui n'auraient pas étés soulevés si l'on avait pas testé le moteur de programmation réactive à une échelle suffisamment "grande". Ainsi, le besoin d'un tel projet s'est révélé finalement bien réel ! |