G-ALG : Gestion d'ALGorithmes                            gilles.hunault@univ-angers.fr       « les aventures de Guillemet et Point-virgule »               (vocabulaire, syntaxe et sémantique dans G-ALG) Table des matières cliquable   1. Enseigner un langage informatique comme une langue...   2. Oubli d'un guillemet, d'un point-virgule, d'une accolade...   3. Mini-anatomie de G-ALG 1. Enseigner un langage informatique comme une langue... Un langage informatique et une langue écrite partagent beaucoup plus qu'on ne le pense généralement, sauf pour APL et le cunéiforme, bien sûr. Enseigner un langage informatique comme une langue doit se faire en tenant compte de deux différences majeures : il s'agit d'une langage écrit et le public, déjà un peu agé, sait lire, écrire et utiliser un ordinateur ou une tablette. La technique d'immersion (voir beaucoup de code court, lire beaucoup de code court, écrire beaucoup de code court) est adaptée. Par contre au niveau de la grammaire, il faut certainement recourir plus rapidement au méta-langage (instructions, séquentialité...) qu'avec une langue en apprentissage oral pour un public jeune. En particulier, il faut utiliser très rapidement les termes précis de la grammaire pour aider les débutants à prendre du recul sur leur code afin de mieux le maitriser. Il ne faut donc pas hésiter à parler très tôt du vocabulaire, c'est-à-dire des mots possibles et des caractères spéciaux ; de la syntaxe, donc de l'ordre des mots pour faire des phrases et des règles de construction des instructions ; de la sémantique, qui permet d'attribuer un sens aux mots et aux symboles spéciaux. Le concept de séquentialité doit aussi être fortement souligné. Un enfant de trois ans sait dire «moi manger maison papi» pour indiquer qu'il voudrait aller manger chez son grand-père, mais avec les quatre mêmes entités lexicales, il sait aussi dire «papi manger maison moi» pour indiquer qu'il voudrait que son grand-père vienne manger chez lui si on admet qu'il s'agit ici aussi d'instructions, c'est-à-dire d'«ordres» à exécuter. Un adolescent, un jeune adulte sera donc capable de comprendre si on lui demande de faire attention à l'ordre des instructions. Une des premières difficultés à utiliser un langage réel pour enseigner l'algorithmique et la programmation est l'abondance des caractères spéciaux et leur sémantique. Il y a par exemple les sigils $ @ % de Perl, les fameux caractères * & du C, les symboles << >> du C++, les notations comme %*% de R... Les blocs d'instruction, avec leurs symboles apparents { et } mais facultatifs pour une seule instruction ou avec un seul symbole de début : et le retour d'indentation comme critère de fin en Python sont très pratiques pour des analyseurs syntaxiques et pour des développeurs confirmés. Pour une initiation, ce sont des pièges mortels car leur oubli affiche des messages d'erreur pour le moins sybillins. La palme du caractère le plus abscons revient au point-virgule, tantôt séparateur tantôt terminateur, avec les conséquences que chacun connait... Pour G-ALG, nous avons fait le choix de limiter le nombre de caractères spéciaux à quatre : le dièse # pour les commentaires, le guillemet droit " pour délimiter les chaines de caractères, les crochets [ et ] pour délimiter les indices de tableau. Il n'y a pas d'accolade donc pas de problème d'accolade, pas de point-virgule, donc pas de problème de point-virgule. Et on ne coupe pas les cheveux en quatre pour savoir s'il y en a quatre fois plus : on ne peut pas afficher directement un guillemet dans une phrase. Tant pis. Maintenant, pour les puristes, les râleurs et les chipoteurs, chr(34) est utilisable dans G-ALG... 2. Oubli d'un guillemet, d'un point-virgule, d'une accolade... L'oubli d'un élément de syntaxe obligatoire comme un point-virgule, un guillemet ou une accolade est une erreur que les langages informatiques détectent en général assez bien, mais parfois trop tard et souvent avec un message peu explicite comme le tristement célèbre unexpected end of file. Prenons comme exemple celui de l'affichage d'un simple "BONJOUR". Le code informatique en PHP peut se réduire à la ligne suivante (sans aucun point-virgule !) <?php echo "BONJOUR\n" ?> alors qu'en C++, il faudra certainement écrire quelque chose comme #include <iostream> using namespace std ; int main() { cout << "BONJOUR" << endl ; return 0 ; } On remarquera qu'aucun langage réel (sauf REXX/REGINA) n'impose d'écrire de commentaire en début de programme alors que tout manuel de programmation indique qu'il faut le faire. Au passage, signalons que G-ALG n'accepte pas d'algorithme sans commentaire au début. Une erreur de débutant(e) consiste à oublier de mettre les guillemets autour d'une chaine, que ce soit les deux guillemets, celui du début ou celui de la fin. Voici, sans commentaire -- mais les messages en anglais parlent d'eux-mêmes et plaident contre l'utilisation d'un langage réel, les erreurs détectées par PHP et C++ : 2.1 Oubli des deux guillemets php bonjour2.php PHP Fatal error: Uncaught Error: Undefined constant 'BONJOUR\n' in /home/gh/Tmp/bjrs/bonjour2.php:1 Stack trace: #0 {main} thrown in /home/gh/Tmp/bjrs/bonjour2.php on line 1 g++ bonjour2.cpp bonjour2.cpp: In function 'int main()': bonjour2.cpp:6:13: error: 'BONJOUR' was not declared in this scope cout << BONJOUR << endl ; 2.2 Oubli du guillemet ouvrant php bonjour3.php PHP Parse error: syntax error, unexpected '"', expecting ',' or ';' in /home/gh/Tmp/bjrs/bonjour3.php on line 1 g++ bonjour3.cpp bonjour3.cpp:6:20: warning: missing terminating " character cout << BONJOUR" << endl ; ^ bonjour3.cpp:6:5: error: missing terminating " character cout << BONJOUR" << endl ; ^ bonjour3.cpp: In function 'int main()': bonjour3.cpp:6:13: error: 'BONJOUR' was not declared in this scope cout << BONJOUR" << endl ; 2.2 Oubli du guillemet fermant php bonjour4.php PHP Parse error: syntax error, unexpected end of file, expecting variable (T_VARIABLE) or ${ (T_DOLLAR_OPEN_CURLY_BRACES) or {$ (T_CURLY_OPEN) in /home/gh/Tmp/bjrs/bonjour4.php on line 2 g++ bonjour4.cpp bonjour4.cpp:6:13: warning: missing terminating " character cout << "BONJOUR << endl ; ^ bonjour4.cpp:6:5: error: missing terminating " character cout << "BONJOUR << endl ; ^ bonjour4.cpp: In function \u2018int main()\u2019: bonjour4.cpp:7:5: error: expected primary-expression before \u2018return\u2019 return 0 ; ^ 3. Mini-anatomie de G-ALG Pour éviter les problèmes de point-virgule et d'accolade, dans G-ALG on a tout bonnement supprimé ces symboles. Une instruction commence toujours par un mot clé -- ce qui n'est pas le cas des langages réels. Il y a les instructions simples qui s'écrivent sur une seule ligne et les instructions composées qui utilisent obligatoirement plusieurs lignes. Lorsqu'une instruction doit s'étendre sur plusieurs lignes, il y a un mot-clé de fin d'instruction, différent suivant l'instruction. La syntaxe des instructions est donc plus "lourde" que dans les langages réels car elle est plus détaillée. Par contre la syntaxe est non ambigue : souvent, dans un langage réel, pour aider l'analyseur syntaxique, les blocs d'instruction partagent une syntaxe minimale, ce qui ne permet pas au premier coup d'oeil de distinguer une accolade fermante comme fin de boucle d'une accolade fermante comme fin de test. G-ALG va plus loin encore, en imposant un symbole de commentaire après chaque fin d'instruction composée. Il en résulte qu'il n'est pas possible d'avoir plusieurs instructions ou plusieurs fins d'instruction sur ligne, contrairement à des lignes comme } ; } }} fréquentes dans les langages réels. Dans G-ALG, les instructions qui doivent tenir sur une ligne sont ECRIRE, LIRE, AFFECTER, APPELER, RENVOYER, OUVRIR, FERMER et QUITTER. Celles qui doivent s'écrire sur plusieurs lignes sont SI, TANT_QUE, POUR, FONCTION. Leur fin s'écrit toujours de la même façon : FIN_SI, FIN_TANT_QUE, FIN_POUR, FIN_FONCTION. Pour insister sur le fait qu'une instruction est un ordre à donner à la machine, il aurait pu être intéressant d'utiliser systématiquement un verbe. On aurait alors dû avoir TESTER_SI au lieu de SI, ITERER_POUR, ITERER_TANT_QUE ou BOUCLER_ POUR, BOUCLER_TANT_QUE au lieu de POUR et TANT_QUE, DEFINIR_FONCTION au lieu de FONCTION, mais à l'usage cela s'est révélé peu productif. Il serait sans doute intéressant de forcer l'indentation du code. Hélas, cela rajoute beaucoup de difficultés (quel espacement ou tabulation, quelles règles...) et pour l'instant G-ALG n'impose rien en ce sens. Par contre, pour les noms des variables, G-ALG, dans la partie analyse, émet une remarque lorsque les identificateurs ont moins de 3 caractères, ce qui n'est pas judicieux en général. Toutefois, dans certains domaines, par exemple lorsqu'on programme des formules de mathématiques complexes, l'usage est d'utiliser rigoureusement les mêmes variables avec les mêmes noms. Pour apprécier la lisibilité des algorithmes écrits en G-ALG, on pourra consulter le manuel de l'utilisateur de G-ALG.   Code-source de cette page.

 

 

   Retour à la page principale de   (gH)