le langage LTR3

LTR3 est dans sa forme très largement inspiré du langage Pascal. On y trouve les déclarations de variables, de types, de constantes, les procédures et les fonctions, les instructions à structure de bloc. LTR3 étant bien sûr postérieur à Pascal (années 80), divers inconvénients propres à ce dernier ont été évités :

• l'ordre des déclarations des types, variables et constantes est libre, ce qui facilite déjà beaucoup la programmation, mais aussi à plus long terme la "génération automatique" de programmes ;
• les blocs BEGIN ... END; ont été remplacés par des blocs DO ... END DO;, IF ... END IF;, etc. – ce qui supprime en particulier la délicate gestion du « else pendant » de Pascal ;
• la distinction entre mot-clé et terme prédéfini est clairement identifiée, ce qui aide à la compréhension du langage et à son emploi ;
• les paramètres des sous-programmes sont explicitement en entrée ou en sortie ou les deux – de ce fait par exemple les paramètres en retour ne sont pas des paramètres passés par adresse pour les besoins du moment, comme il faut le faire en Pascal.

LTR3 introduit la notion d'exception : déclaration, signalisation et traitement d'exception permettent de gérer dans le texte du programme les situations exceptionnelles, soit prévisibles (les exceptions prédéfinies) soit redoutées (les exceptions utilisateur). On notera que la notion, d'introduction récente, a presque aussitôt suggéré à certains une programmation systématique par exceptions [BBG 85] ; ce point de vue me paraît un peu dangereux, puisque alors l'occurrence vraie d'une exception est indécelable – s'agit-il d'un cas "normal" d'exception, ou d'un cas réellement exceptionnel ? on appauvrit considérablement la notion, qui n'est plus le traitement, dans le texte du programme, des cas d'erreur, mais un traitement "un peu particulier" présenté dans une syntaxe "un peu particulière".

Un des traits essentiels du langage est la modularité. Elle se présente sous deux aspects :

• Un programme LTR3 est composé d'un assemblage de modules, unités syntaxiques dans lesquelles on regroupe des termes du langage « sémantiquement liés » ; un module utilise les déclarations présentes dans d'autres modules par une mention explicite d'utilisation, qui nomme le module employé, et qui n'est pas transitive – cette dernière propriété permet d'éviter des collisions entre identificateurs semblables qui ne seraient pas directement visibles.
• On a une séparation textuelle de l'interface et du corps du module :
  • l'interface est la zone des déclarations exportées par le module – l'ensemble des déclarations que verront les modules utilisateur ;
  • le corps est la zone de réalisation des déclarations d'interface, où figurent les corps des sous-programmes exportés, et des déclarations locales au module – ces déclarations locales ne sont pas visibles des modules utilisateur.

On trouve aussi la notion de type opaque, qui permet de construire, dans un module, un type abstrait de données ; la simplicité de définition du type opaque rend cependant son usage assez limité.

Mais LTR3 est aussi un langage Temps Réel (version 3). Les aspects du Temps Réel sont définis dans le langage et non introduits en supplément du langage. LTR3 connaît la notion de tâches immédiates – les interruptions – et de tâches différées – avec une priorité à la création des tâches. La synchronisation est réalisée par divers outils : des types prédéfinis ressource, événement, événement impulsionnel, des sections critiques, ... On observe un certain panachage entre les concepts de base du langage, introduits par des mots-clés, et les concepts prédéfinis, ce qui laisse à penser qu'il serait difficile de compléter ou d'améliorer les notions de base de la synchronisation entre tâches. Ces notions sont cependant suffisamment communes et générales pour que l'inconvénient ne paraisse pas trop majeur.

Le dernier point concerne les entrées/sorties. Elles sont standards ou formatées. Les entrées/sorties standards traitent des fichiers, dont on peut regretter qu'il s'agisse uniquement de fichiers séquentiels. Les entrées/sorties formatées permettent un dialogue à l'écran – READ et WRITE. On ne peut pas directement accéder aux adresses physiques de la machine, ce qui est malheureusement un peu limitatif.