Le support de l'interaction dans les langages de programmation

Le langage de programmation consiste a priori en une syntaxe ainsi que des règles de grammaire, qui permettent d'exprimer des ordres à donner à une machine. La complexité des ordres donnés dépend de la puissance d'expression du langage, et est conditionnée par les types de problèmes ciblés par le langage. La plupart des langages de programmation aujourd'hui ciblent en priorité le calcul scientifique et la communication de données (avec les périphériques de stockage, ou entre machines). En pratique cela signifie que leurs concepts de base sont très adaptés au calcul (opérations arithmétiques, fonctions mathématiques, paradigme MapReduce de traitement de données, etc.), et aux communications (lecture/écriture dans des flux de données, abstraction des descripteurs de fichiers, attente asynchrone, etc.). Outre ces concepts, l'interaction ne semble pas être supportée explicitement dans les langages de programmation courants.

Qu'entend-on par supporter l'interaction dans un langage de programmation  ? Il s'agit de faciliter la

programmation d'applications interactives à bas niveau — c'est-à-dire la création de programmes qui reçoivent des données issus de périphériques d'entrée, et émettent des données vers des périphériques de sortie, afin de réaliser une boucle de perception-action du point de vue de l'utilisateur. En entrée, on contrôle principalement les ordinateurs au clavier et à la souris pour les ordinateurs de bureau, et au doigt pour les smartphones. En sortie, la majorité des applications interactives utilisent un écran

matriciel (une matrice de points colorés). D'autres types de périphériques sont utilisés dans des contextes spécifiques (manettes, voix, regard, audio, haptique, etc.), cependant le support limité des périphériques de base nous incite à nous concentrer d'abord sur eux. Un support essentiel de la programmation d'interactions consiste donc en le triplet clavier/souris/écran.

Pour expliquer notre idée d'un meilleur support des périphériques d'interaction, il convient d'abord de décrire leur support dans les systèmes informatiques actuels. Commençons par prendre l'exemple du langage C, car c'est un exemple clair, et le second langage le plus utilisé aujourd'hui (septembre 2019) d'après l'index TIOBE  [Tio19]. Le cœur du langage supporte principalement  : les variables, les types, les pointeurs, les enregistrements struct, les tableaux, les énumérations, la portée lexicale, les fonctions, les blocs conditionnels, les boucles, les branchements goto, les opérations arithmétiques/binaires/logiques, les entiers, les nombres à virgule flottante, les nombres complexes, les chaînes de caractères, l'import/export de symboles externes, et un préprocesseur [ISO18]. Ensuite, tout langage possède une bibliothèque “standard”, qui implémente les fonctionnalités ne nécessitant pas de support syntaxique du langage, et s'expriment simplement par des fonctions. Le langage C fournit les modules suivants  : assert.h, complex.h, ctype.h, errno.h, fenv.h, float.h, inttypes.h, iso646.h, limits.h, locale.h, math.h, setjmp.h, signal.h, stdalign.h, stdarg.h, stdatomic.h, stdbool.h, stddef.h, stdint.h, stdio.h, stdlib.h, stdnoreturn.h, string.h, tgmath.h, threads.h, time.h, uchar.h, wchar.h, et wctype.h.

Parmi ces deux niveaux (syntaxe et bibliothèque standard), le langage C ne spécifie aucun support du triplet clavier/souris/écran. Seules les conventions UNIX et POSIX permettent d'intégrer un support rudimentaire avec l'utilisation de fichiers : l'entrée de texte au clavier et le retour visuel dans un terminal textuel. C'est à partir du système d'exploitation qu'on dispose d'un support suffisant des périphériques d'interaction, cependant de nombreuses alternatives existent et compliquent le choix des programmeurs : GNU Readline, OpenGL, conio.h (MS-DOS), ncurses (UNIX), Newt (Linux), X11 (UNIX), Wayland (Linux), Framebuffer (Linux), DRM (Linux), KMS (Linux), evdev (Linux), udev (Linux), libinput (Linux), GDI (Windows), Direct2D (Windows), DirectDraw (Windows), DirectWrite (Windows), QuickDraw GX (macOS), Carbon Event Manager (macOS), Quartz 2D (macOS), Metal (macOS). Ici nous n'avons énuméré que des bibliothèques natives des différents systèmes. En outre il existe un grand nombre de bibliothèques qui se basent sur les précédentes, fournissent des services similaires, et contribuent à compliquer la topologie des outils de programmation d'interaction dans les systèmes informatiques.

Cette situation peut s'expliquer par les changements historiques des modalités d'interaction en entrée et sortie. Bien que l'usage du clavier et de la souris soient standards depuis maintenant plus de 40 ans, leurs caractéristiques ont beaucoup évolué. Les claviers ont évolué principalement dans les dispositions des touches et les touches “spéciales” (commandes, contrôle multimédia). Les souris ont évolué dans les types de capteurs, la précision de la molette, les boutons présents, ainsi que les fonctions de transfert entre déplacement physique et position du curseur à l'écran. De plus, de nombreux périphériques ont été développés qui ont tenté de faire évoluer ces modalités d'interaction standard, comme par exemple la souris 3D, le trackpad, ou le clavier “méduse”. Face à ces évolutions, les fonctionnalités d'interaction ont pu être considérées comme instables dans le temps, et dissuader

matérielle, touches multimédia non reconnues), sans empêcher le système d'exploitation de fonctionner correctement. Or la spécification de toute fonctionnalité d'un langage implique qu'elle doive fonctionner sur tous les systèmes, donc qu'elle est sous la responsabilité des concepteurs de compilateurs. Dans ces conditions, un support de l'interaction dans les langages obligerait les concepteurs de compilateurs à suivre les évolutions des périphériques d'interaction, et demanderait un travail de maintenance conséquent, ce qui peut expliquer que l'interaction n'y figure finalement pas.

Comment formuler une recommandation réaliste et réalisable dans cette situation ? Nous proposons trois

pistes de solutions, sans en choisir une en particulier pour le moment. La première possibilité est d'inclure dans les langages les fonctionnalités stables depuis plusieurs décennies :

pour le clavier, les évènements d'appui et relâchement de touche, avec le code de position de la touche et le caractère imprimable correspondant

pour la souris, les évènements de déplacement physique relatif, d'appui et relâchement de bouton, et de déplacement physique de la molette

pour l'écran, l'évènement de synchronisation avec le rafraîchissement de l'affichage, avec la matrice de couleurs à éditer

Ces fonctionnalités sont basiques, mais faciliteraient le développement de bibliothèques logicielles robustes et multi-plateformes. En effet, elles ne nécessiteraient pas d'utiliser une bibliothèque dédiée pour chaque périphérique et chaque système, et réduiraient ainsi l'apprentissage nécessaire. Ensuite, par leur inclusion dans le langage elles ne nécessiteraient pas l'installation de bibliothèque tierce, ni d'actions spécifiques pour les activer, ce qui améliorerait leur accessibilité. Enfin, nous conjecturons que leur inclusion dans un langage (aux côtés de fonctionnalités basiques telles que la manipulation de texte ou les accès aux fichiers) les forcerait à adopter une interface simple, qui puisse raisonnablement être supportée par les compilateurs tout en conservant une certaine puissance d'expression.

Une seconde possibilité est de reconnaître la longévité de certaines bibliothèques logicielles liées à l'interaction, et de faciliter l'utilisation de leur API. On pourrait ainsi imaginer que le compilateur initialise automatiquement ces bibliothèques, s'il détecte que leurs fonctions sont utilisées. De plus il ne serait pas nécessaire d'installer ces bibliothèques en plus d'un compilateur, pour avoir à les utiliser. Enfin, la standardisation de ces bibliothèques faciliterait le dilemme du choix lorsque des alternatives existent, et contribuerait à les renforcer ainsi que leurs communautés en ligne. Parmi ces bibliothèques, nous pouvons citer :

OpenGL (1994), pour le rendu 3D

FreeType (1996), pour le rendu des polices de caractères SDL (1998), pour la gestion des fenêtres et entrées

Enfin, une troisième possibilité est d'intégrer le support de l'interaction dans la syntaxe des langages, plutôt qu'en utilisant des fonctions. Ces mécanismes étendraient les langages de programmation, pour exprimer l'interaction de façon plus “native”. Un exemple d'une telle extension est le support de la souris dans le langage Processing [Rea14], qui consiste en des variables globales comme mouseX et mouseY, et des noms de fonctions comme mousePressed() qui sont appelées automatiquement lors d'un appui de la souris.

La troisième piste nous semble la plus intéressante, car elle reconnaît le caractère essentiel de l'interaction dans la programmation. Après tout, il nous serait impossible d'observer le fonctionnement d'un programme, ni d'agir dessus, sans un support minimal du triplet clavier/souris/ écran. Nous nous sommes donc attachés à proposer des concepts qui puissent s'intégrer naturellement dans les langages de programmation, non pas en tant qu'appels de fonction mais comme syntaxes natives. Dans ce travail de thèse, nous proposons une extension du langage Smalltalk dédiée à l'animation, que nous présentons en section 2.4. Enfin dans le framework présenté au chapitre 3, nous représentons les périphériques d'interaction comme des objets globaux, que l'on peut interroger à tout moment pour observer les évènements d'entrée.