Seventh, le micro langage impératif de ZDS !

Je ne suis pas sûr qu'une syntaxe comme ça aide tellement pour le parsing : dans un langage fonctionnel comme Lisp, elle permet d'exprimer simplement et naturellement des applications de fonctions (et on n'a besoin de rien d'autre), mais ici ce n'est pas ce dont vous avez besoin. Vous avez besoin d'exprimer des affectations de variable, des séquences d'instruction et des structures de contrôle (conditions et boucles), et la syntaxe avec des parenthèses partout n'est pas spécialement plus adaptée qu'une syntaxe classique à la C avec des accolades (la preuve : vous avez quand même des affectations x=5, et tu es obligé d'avoir inventé une syntaxe ad hoc un peu foireuse pour les paramètres - que tu vas devoir parser aussi.)

Entendons-nous bien : la syntaxe n'est pas le point principal du langage, ce qui est important, c'est les idées qu'elle permet d'exprimer. Mais en l'occurrence, la syntaxe que vous avez choisie n'est pas vraiment adaptée à l'expression des concepts impératifs, c'est donc une bonne idée de réfléchir un peu à ces concepts pour trouver une façon plus naturelle de les écrire (et pas forcément plus compliquée - en plus vous pourriez en profiter pour apprendre PLY, tant qu'à faire). Par contre, clairement, un débat sur "est ce qu'il vaut mieux des accolades ou begin/end, et ; ou , pour les arguments" n'a strictement aucun intérêt. Un conseil seulement : évitez la syntaxe avec indentation comme en python, c'est un peu pénible à parser.

Le problème, c'est que vous mélanger syntaxe infix et prefix dans un dialecte (le lisp) qui a été pensé pour être prefix avant tout notamment avec (x = a)¹. Cela peut notamment amener à des misconceptions sur ce qu'on peut imaginer du langage (comme se poser légitimement la question si il est possible d'écrire (5 + 5)).

Ensuite, je vais reprendre un vieux message² qui vient de PdP qui explique succinctement l'idée que vous devriez vous faire de la syntaxe. Le post est très long mais je vous invite vraiment à le lire car c'est un bon début de piste en ce qui concerne le travail en rapport avec la syntaxe.

Je vais te dire pourquoi je n'ai pas regardé la syntaxe du langage - mais ne t'inquiète pas, j'ai fait aussi l'erreur.²

Dans le développement d'un langage informatique, quand on est débutant et qu'on lit les ressources tel que le Modern Compiler Implementation in ML³ ou des livres plus anciens tels que le Dragon Book⁴, le premier chapitre parle de lexique et de syntaxe. Grosso-modo, on commence déjà par décrire la syntaxe d'un langage informatique comme vous le faites ici.

Cette technique d'apprentissage est très bien quand on est supervisé. Elle a l'avantage de produire quelque chose de concret assez rapidement ce qui permet au lecteur d'avoir un résultat de son travail assez rapidement. Aussi, la première phase d'un compilateur/interpréteur est l'analyse lexical et syntaxique (ce qu'on nomme communément le front-end). Pourtant, cela n'en fait pas⁵ la partie la plus intéressant. Je dirais même que c'est un piège de commencer par cette partie dans le développement d'un nouveau langage.

Un front-end à la mano ?

J'ai un peu regardé le code disponible et cette remarque convient parfaitement dans le sens où vous vous amusez à faire à la main le front-end. Je juge pas de la qualité de votre code mais surtout de la direction prise dans le développement.

Alors l'analyse lexical et syntaxique, théoriquement c'est ce qu'on nomme un automate à état fini et un automate à pile respectivement. Si vous avez la curiosité de voir les liens, vous verrez que c'est pas super beau à voir dans le sens où ce sont des modèles dont l'explication est, je trouve, complexe pour un néophyte de l'informatique et dont l'implémentation n'est guère intéressant. Ce sont pourtant des modèles basiques que tout informaticien digne doit connaître (dans les grandes lignes). Donc vous devez les apprendre.

Vous pouvez voir une implémentation d'un automate à état fini ici par Russ Cox pour vous faire une idée de ce que c'est. En plus en cadeau, vous avez un tout petit automate à pile dans le lot ici (c'est la fonction re2post) — mais je vous invite à lire le cours de @nohar sur le sujet qui vous en apprendra toutes les subtilités. Enfin, si vous regardez bien, c'est une implémentation d'un moteur d'expression régulière — en réalité, c'est une application du théorème de Kleene qui dit que pour tout automate à état fini, on peut y associer une expression régulière. Alors, montrer comme ça, ça à l'air chiant. Et ça l'est comme le dénote ce commentaire dans les sources du compilation OCaml sur l'analyse lexical.

En réalité, dans tout langage digne de ce nom, on ne refait plus d'automate à état fini ou d'automate à pile pour créer le lexique et la syntaxe du langage parce que c'est chiant. On utilise des générateurs d'automate à état fini et automate à pile qui sont respectivement pour le C Flex et GNU Bison — tu as les équivalents en OCaml avec ocamllex et menhir ou ocamlyacc (@nohar à la rescousse pour Python). Et ces outils, on les utilise partout comme PHP par exemple ou OCaml avec son propre outil. Il faut savoir que ces outils ont une portée historique, en faite il existe encore aujourd'hui les outils lex et yacc qui ont servit à implémenter le premier compilateur C (donc un vieux compilateur), ce sont des outils qui ne viennent pas de nul part. Conventionnellement, lors d'un bootstrap du langage, on lui associe ce genre d'outil portant quasiment le même nom. C'est pour cette raison que vous retrouverez pour la quasi-totalité des langages un équivalent à lex et yacc en plus ou moins évolué comme c'est le cas en OCaml⁶.

Ce que je veux dire par là, c'est qu'il faut utiliser ces outils. Non pas parce que c'est moi qui le dit mais parce qu'ils sont fait exactement pour ça, pour créer des langages informatiques. Faire le front-end à la main n'a qu'un intérêt didactique qui reste très limité car vous n'arriverez certainement pas à faire une implémentation équivalente à ce que produit Flex et GNU Bison autant sur la performance que sur la fiabilité, la productivité et surtout la modularité (et si vous voulez rajouter une nouvelle construction au langage ?). C'est factuel. BLABLABLA COURS DE THIZANNE BLABLABLA⁷.

Prendre la bonne direction

Même si la plupart des cours (je dirais même tous) commence par l'implémentation d'un front-end, lors de l'implémentation d'un nouveau langage informatique, ce n'est pas dans cette direction qu'il faut partir. Ce qui fait un langage informatique, ce n'est pas la syntaxe et le lexique, c'est la sémantique.

Pour reprendre un exemple simple, ce qui fait que vous comprenez le mot patate, ce n'est pas la juxtaposition de ses lettres, non plus la liaison entre celle-ci mais la définition du mot patate. C'est cette définition qui est importante, qui délivre l'idée. Tu peux apprendre à un gamin de 2 ans que pour décrire une carotte, il faut dire patate et quand il demandera des carottes, il demandera des patates (en tout cas, le concept lié à ce que nous considérons comme des patates) — ça ne reste qu'un mot, et c'est bien pour cette raison qu'il est différent de la langue française et anglaise quand bien même le concept reste le même.

Ce que je veux dire, c'est qu'importe qu'on est le mot-clé define ou =, l'idée derrière reste la même, à savoir l'assignation d'une valeur à une variable.

Ce qui m’amène au centre de l'explication. C'est que ce n'est pas la syntaxe qui dirige ton langage mais la sémantique. Définir d'abord les concepts de ton langage (comme le paradigme impératif) va vous permettre de vous diriger vers une syntaxe spontané (une syntaxe pensé pour vos concepts). Et plus haut, j'ai dit avoir fait la même erreur — et c'est se que vous faites en vérité. Comme vous, j'ai voulu créer mon langage mais dans l'exercice⁸ que l'on m'avait proposé, on m'avait imposé une syntaxe proche du lisp — comme vous. Ensuite, au fur et à mesure, je me suis mis à implémenter le concept de programmation fonctionnel. Non pas parce que j'aime la programmation fonctionnelle (je ne la connaissais pas avant) mais parce que la syntaxe du lisp dérive d'une sémantique de langage fonctionnel. Ce n'est pas moi qui est choisi d'en faire un langage fonctionnel, c'est la syntaxe.

Ce que je veux dire au final, c'est que partir sur la syntaxe directement va obligatoirement vous fermer des portes sur des concepts. par exemple, partir sur une syntaxe comme le C exclut la programmation fonctionnelle — ou tout du moins, essayer d'intégrer un tel concept ne donnerais pas une syntaxe spontané — et c'est le cas par exemple avec Python et ses closures⁹. Et de cette expérience, je juge un langage d'abord par les concepts qu'il implémente et ensuite par sa syntaxe (car elle est tout de même importante¹⁰) et c'est pour cette raison que je n'ai pas regardé la syntaxe de votre langage.

Conclusion

Si vous deviez donc faire un nouveau langage, vous devriez partir sur les concepts qu'il propose avant — et pour le coup, vous commencer à avoir une idée claire. Ensuite, vous éluderez une syntaxe de manière spontané (qui serait proche d'un langage ou non comme le C). C'est pourtant un travail difficile et c'est pour cette raison que les langages syntaxiquement sont proches - on a toujours besoin d'un pied à terre. Mais puisque que syntaxiquement ils sont proches, ils sont aussi sémantiquement proches.

Enfin, j'aimerais que vous portiez votre attention sur un débat sur ce que peut être un langage informatique français (autre lien). Cela présente surtout une extension du débat syntaxe/sémantique visant particulièrement l'idée que l'on peut avoir de la simplicité (toute subjective) d'un langage — et ma conclusion est qu'un langage informatique français n'est pas forcément synonyme d'un langage informatique simple, cette simplicité doit se retrouver dans la sémantique.

EDIT: il doit y avoir des fautes, mais là, je suis très fatigué

Pourquoi faire un truc si compliqué/peu commun ? J'ai pas trop le temps de regarder les détails de ta syntaxe mais je trouve ça lourd pour rien. Si j'étais toi, déjà, je partirai sur un pseudo basic avec des délimiteurs clairs et ne travaillant que sur des entiers dans un premier temps.

Par exemple un truc comme ça (fortement inspiré du Pascal mais sans typage explicite puisque toutes les variables sont des entiers) :

1
2
3
4
5
6
7
8
9

function factorielle(n)
begin
  if n <= 1 then
    factorielle = 1
  else
    factorielle = n*factorielle(n - 1);
end;

print(factorielle(10))

Si déjà tu parse ça, tu aura une bonne base de langage impératif simple et clair et tu pourra l'étendre. Et fondamentalement c'est pas très compliqué à parsé puisques les blocs sont délimités par des begin/end et les instructions par des points virgules.

Tu fais comme tu veux mais je pense que tu devrais vraiment pas te prendre la tête a court terme. Selon moi pour commencer tu devrais juste définir :

• Comme définir une fonction,
• L'affectation,
• Les opérations arithmétiques de bases,
• une fonction print,
• Eventuellement un if/else

Pour le reste, tu verra plus tard, ça se rajoutera.

Le pascal que je te propose a l'avantage de rester simple a parser (car il y a pas mal de délimiteurs). Il y a effectivement une difficulté, c'est que les opérateurs ne sont plus infix mais vu que tu nous a dis déjà avoir fais un parseur de lisp, ça fait un petit challenge! Je pense que c'est largement faisable.