Acid, le lisp-like de la communauté !

Après réflexion, je pense qu'il serait mieux de commenter en français.

Hmm. Je suis mitigé sur ce point. Mais je ne suis pas représentatif d'un débutant qui va bosser sur ce projet. Mon principal soucis c'est que commenter en français va te demander de maintenir deux lexiques : le vocabulaire français et l'équivalent anglais pour se dépatouiller de la doc sur le net.

Ça par contre, +1. D'autant que lorsque le langage sera arrivé à maturation, vous serez largement en mesure d'écrire un gros tuto pour montrer au monde entier comment vous avez fait, quelles difficultés vous aurez rencontré et comment vous les aurez dépassé.

Grosse plus-value !

Peut-être que The Super Tiny Compiler (en) pourrait aider les débutants à comprendre un peu comment un compilateur/interpréteur fonctionne : comment on passe d'un fichier texte à quelque chose de compris par la machine.

Gros +1 !

Même si je deteste le js, je dois avouer que ce code est génial d'un point de vue didactique. C'est ce que je disais à AlphaZeta : l'idéal serait de faire un code style tuto avec beaucoup de commentaires qui expliquent ce qu'il se passe. Même avec des bases sur le sujet ce genre de code n'est pas évident à lire, alors pour un débutant ça risque d'être compliqué.

Ça dépend de l'objectif du projet. Apprendre ou enseigner ?

Si le but est de se former, gardez un code lisible et maintenable sans le noyer sous des tonnes de commentaires qui vont mentir au bout de 3 corrections de bugs. Votre code va énormément bouger, donc le documenter à part est certainement beaucoup plus judicieux.

Vu que tout le monde semble ok, partons sur la proposition de Dominus.

Vous pouvez développer une implémentation dans votre langage favoris de votre côté ou tout partager sur le repo Github centralisé.

D'ailleurs pensez-vous qu'il serait plus judicieux d'ouvrir un repo Github pour chaque langage d'implémentation ? Quitte à forker les repo des membres.

Pour l'idée de la Doc à part dans chaque fichier, c'est une excellente idée

PS : J'ajoute dés que possible les ressources partagées dans le fichier "guide du contributeur".

On peut toujours commenter en anglais et écrire en français sur les fichiers markdown.

Ou même commenter en français et utiliser des mots anglais pour le vocabulaire technique.

@the_new_sky: je pense qu'un langage par repo est plus adapté, surtout si on adopte différentes architectures de code (parce que dans ce cas là on partagera même pas les fichiers markdown).

On peut toujours faire une branche par implémentation, mais c'est pas vraiment fait pour ça

On peut toujours faire une branche par implémentation, mais c'est pas vraiment fait pour ça

C'est vrai que ce serait très moche… Mais en même temps rassemblé tout au même endroit peut être intéressant : la majeure partie des choses qui vont différées ce sont les implémentations en différent langages, une fois ceci fait la lib standard devrait être à peu de chose près identique pour tous non ? Du coup on commencerait par 1 branche/langage de base puis tout serait merge pour continuer le projet

Moi je suis chaud pour l'implémenter en haskell mais j'ai quand même à apprendre encore vu que ça fait même pas une semaine que je me suis lancé dans le langage (et le paradigme fonctionnel en même temps). Donc si un (ou plusieurs) membre(s) expérimenté(s) veut/veulent bien le faire avec moi ce serait cool. On pourrait appeler l'implémentation HAcid/Hacid.

J'ai fait quelques modifications au niveau des commentaires, et j'ai ajouté un début de fichier markdown. Si quelqu'un peut me proposer d'autres améliorations… J'ai essayé le plus possible d'expliquer mon code mais j'ai pas l'habitude de travailler en communauté donc je prends les conseils.

J'ai pas compris cette histoire d'AST représenté sous forme de YAML/JSON.

Pourquoi pas directement traduire ça en AST Python avec le module ast ?

@Folaefolc: Mauvaise idée je pense, il faudrait mieux représenter ça avec un AST à proprement parler (avec des nodes et tout, comme dans mon code) à mon avis.

Edit: Ah on parle de la représentation dans un fichier ? J'ai rien dit alors…

Je note ! Ça me paraît pas mal, je vais essayer d'aller vers quelque chose comme ceci pour voir ce que ça donne.

bonne représentation = facile à générer + facile à transformer en AST + (optionnel) human-readable, et celle-ci m'a l'air d'assez bien adhérer aux trois critères, même s'il faut l'essayer encore pour s'en assurer.

@AlphaZeta : C'est pour l'utiliser dans les implémentations faîtes en d'autres langages, donc oui, c'est pour mettre dans un/des fichiers.

EDIT : Si quelqu'un pourrait rédiger un petit programme en Acid pour qu'on ait un objectif à réussir à parser, ce serait super

@mehdidou99: Euh mais attends, ça veut dire qu'on va parser le code en Python (par exemple), écrire l'AST dans un fichier, puis lire ce fichier pour l'exécuter/compiler en C++ (encore par exemple) ?

Non : on parse avec le langage que l'on veut, on génère une représentation en json, puis le script python que je vais créer transforme ça en AST python, pour qu'il puisse être interprété par l'interpréteur python.

H.S : je suis à l'instant en train de découvrir une bibliothèque C++ pour le json qui a l'air fort agréable à utiliser; donc je suis content.

J'ai mis à jour Github, les implémentations sont désormais séparées du repo central.

Repos actuellement ouverts (2)

• Repo central : Contient les specs, des ressources utile et des conseils.
• Implémentation Python : Implémente… en Python !

Non le but du jeu est d'avoir une représentation serialisée, facile à comparer pour les tests unitaires, qui puisse permettre accessoirement d'écrire un parseur dans un autre langage que Python tout en ayant le même interpréteur.

Après, honnêtement, c'est pas un passage obligé pour un parseur Python : vous pouvez tout à fait générer les ast directement au lieu de les sérialiser, mais si vous voulez tester efficacement le parseur ça me semble quand même une bonne idée qui ne mange pas de pain, de gérer les deux sorties.

Ça permet aussi de tester les ast python plus facilement à la main (parce que le module est touffu)

PS : j'ai une demi heure à tuer, je vais voir pour vous préparer un script utilitaire.

Bon du coup j'ai soumis la PR sur PyAcid

Excusez moi, mais il me semble ne pas avoir compris cette histoire d'AST.

De ce que j'ai lu, l'idée est en-gros de convertir le code Acid en AST Python, de manière à qu'il soit possible de l'exécuter dans l'interpréteur Python. Dans ce cas, peut importe les implémentations (qui ne feraient "que" traduire Acid en AST Python) l'exécution aurait toujours lieu au même endroit.

C'est bien cela ?

Oui. Mais le truc, c'est que l'AST Python, tu ne peux le générer qu'en python. Du coup, je vais créer un script Python qui convertit une représentation (en json) en AST. Comme ça, les parsers dans les différents langages génèrent cette représentation, et tout est interprété au même endroit.