Acid, le lisp-like de la communauté !

Dans ce cas, la majorité l'emporte

Je pense que c'est important en effet

Désolé de ma méconnaissance mais qu'est-ce qu'un système de FFI ? J'ai cherché un peu mais sans grand succès

Foreign Function Interface, c'est pouvoir appeler du code en zAcid depuis un autre langage et réciproquement. Par exemple, en C je peux appeler des fonctions Python si j'utilise la bibliothèque qui va bien, et en Python je peux appeler du code C.

Sinon, je rejoins l'idée d'implémenter le plus possible de choses en zAcid pour faciliter le port vers un autre interpréteur.

Cette histoire de Python a été mal comprise : vous pouvez tout à fait écrire votre langage et son compilateur de telle manière qu'il soit convertit en bytecode Python, et ainsi qu'il s'exécute dans l'interpréteur CPython.

Les avantages à cela sont multiples :

• se concentrer dans un premier temps sur la syntaxe et la sémantique du langage, donc uniquement la partie frontale du compilateur, sans s'emmerder à écrire un interpréteur en parallèle, donc se concentrer sur l'essentiel, la sortie du compilateur étant un AST python standard,
• Pouvoir tirer partie des builtins de Python et des modules de sa bibliothèque standard le temps de développer la bibliothèque de votre langage dans votre langage,
• Rendre votre langage immédiatement compatible avec C, C++, Rust, etc. en vous servant du mécanisme de binding ou du module ctypes de Python, sans vous péter les dents sur une passerelle codée a la mano.

Bref, l'idée c'est d'abord de se concentrer sur ce qui est le plus important dans votre langage. Et pour avoir déjà fait ce genre de travail (y compris au boulot), le bénéfice que cela génère fait toute la différence entre un projet de langage qui marche et qui va jusqu'au bout, et un n-ième langage pas fini, mal spécifié, où les gens passent leur temps à debugger un interpréteur ou bien se decouragent parce qu'il faut bosser hyper longtemps avant d'avoir le moindre résultat.

En bossant de cette façon, c'est-à-dire en reposant sur des composants qui fonctionnent le temps de coder les votres, vous concentrez l'effort à chaque phase sur ce qui est réellement important pendant cette phase, et vous pouvez jouer avec votre langage dès le début, ce qui est tout de suite beaucoup plus encourageant.

En somme, l'idée est de se servir de Python comme échafaudage.

Salut,

J'ai soumis une première PR avec un parser minimaliste, juste pour poser les bases.

AZ.

Tu pourrais, vaguement, expliquer ce que tu as fait ? Parce que bon,

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

class IntLiteral(Literal):
    """
    Integer literal expression.
    ex: `42`
    """

    abstract = False

    @classmethod
    def feed(cls, token_queue):
        token = token_queue[0]

        if token.type == TokenType.INT_LITERAL:
            token_queue.pop(0)
            return cls(int(token.value))
        else:
            raise ParseError(token.pos, "Unexpected {}".format(token.type.name))

, je ne pense pas que tout le monde comprenne immédiatement. Moi le premier.

Et j'ai pris 20 ligne au hasard…

Je commenterai ça demain, merci de me le rappeler

Sinon pour ce code précis, je déclare une méthode de classe (via le décorateur classmethod), qui est fait juste une méthode qu'on appelle de cette façon: IntLiteral.feed(token_queue). Ça ressemble aux méthodes statiques des langages comme Java ou C# en gros, sauf que la classe elle même est passée à la fonction (il s'agit ici de mon paramètre cls). Cette méthode consomme la liste de lexèmes et retourne un objet IntLiteral si le premier élément est un lexème qui représente un entier, sans se soucier de rétablir la liste en cas d'échec, c'est pour ça qu'on a la méthode consume qui gère tout ça.

PS: Je suis super mauvais pédagogue

+1 Gabbro. Dans un premier temps, il peut être judicieux d'acquérir les bases théoriques. Là, il y en a qui font des PR alors que d'autres ignorent ce qu'est un AST. Pas très collaboratif il me semble.

Si ce n'est pas trop précipité, je propose de passer aux specs ? Comment doit-t'on s'y prendre ?

PS : Toute pull request envoyée avant les specs ne sera évidemment pas mergée pour le moment.

@Vayel: Ouais pas faux, mais comment mettre à niveau tout le monde (surtout avec mes talents pas terribles de pédagogue) ?

Il n'est pas possible de mettre tout le monde à niveau, d'autant plus que nous somme sensé fournir uniquement les specs du langages, des ressources et du soutient mais un code peut être centralisé mais ce n'est pas obligatoire.

Bref, dans l'idéal, il faudrait commencé à réfléchir à la théorie : les specs

Je viens de consulter mon ami Google, et je n'ai pas trouvé de ressources sur la génération d'AST Python à partir d'un autre langage. Quelqu'un pourrait-il m'éclairer ?

Bref, dans l'idéal, il faudrait commencé à réfléchir à la théorie : les specs

Dans l'idéal, il faudrait surtout arrêter de vous prendre le chou sur des détails et commencer à coder. Ça fait 9 jours que l'idée a été lancée, et en 9 jours vous vous êtes à peine mis d'accord sur "ok nous on parse une syntaxe qui ressemble à lisp et on fait ça en python", alors que vous aviez des propositions raisonnables quelques heures après le premier message, il me semble. Pour un projet de cette envergure, c'est loin d'être efficace.

Pour ce qui est « des specs », c'est complètement contre-productif d'y passer plus de 5 minutes. Vous n'allez de toute façon pas implémenter un langage qui servira à quoi que ce soit de concret : le seul intérêt de ce projet, c'est d'apprendre en pratiquant, et vous n'apprendrez rien en discutant sur « est-ce qu'il vaut mieux écrire fun ou lambda, et est-ce qu'on met ce truc qu'on aura jamais le temps d'implémenter dans la syntaxe ou pas ». Et comme de toute façon personne du projet n'a la moindre idée de comment on conçoit correctement un langage (c'est normal, c'est une compétence rare et un problème difficile, la preuve, C++ existe), vous pouvez discuter autant que vous voulez, le résultat sera probablement moyen de toute façon.

TL;DR : vous avez déjà une proposition de syntaxe citée au tout début de topic, arrêtez de perdre du temps et partez là dessus.

Ce message va sans doute paraître agressif à ceux qui préféreraient discuter le plus possible pour se donner l'impression d'avancer, mais ce n'est pas le cas. Il est là pour vous aider à avancer dans la bonne direction : je n'ai aucun intérêt particulier à ce que le projet avance (et ce n'est intéressant ni pour moi, ni pour vous que j'écrive du code), donc faites comme il vous plaira, je ne vais pas me battre contre les bonnes (ou les mauvaises) volontés

Les AST de Python sont implémentés dans le module standard ast.

Celui-ci te propose en particulier une fonction parse() que tu peux utiliser pour parser une expression ou un code en Python et obtenir l'AST équivalent. Ça aide à découvrir progressivement les classes pour comprendre comment les utiliser concrètement.

Un AST peut être compilé en bytecode avec la built-in compile().

PS : +1 pour que vous commenciez direct sur la spec de Dominus. Si vous passez trop longtemps avant de commencer à coder vous ne démarrerez jamais. Bossez de façon itérative : faites un premier parseur basique puis faites-le évoluer au fil du temps.

Le cheat-mode serait d'utiliser un parseur comme PLY directement.

Ton raisonnement ne se tient pas : "de toute façon, vous allez faire quelque chose de médiocre, alors précipitez-vous, comme ça ce sera encore plus médiocre" (je caricature, bien sûr).

De plus, lorsque l'on discute, on ne se donne pas l'impression d'avancer : on avance effectivement. La preuve, en 9 jours, on a un début de spécification, alors que je te rappelle que ceci est un projet communautaire : on ne peut pas décider rapidement en fonction de ce qui nous plaît, car il faut débattre pour se mettre d'accord, contrairement à un projet où on est tout seul. Ainsi, nous sommes très efficaces : ce n'est pas parce qu'il y avait de bonnes idées au départ qu'on les adopte tout de suite, car il faut les débattre en communauté. 9 jours pour un début de spec, c'est très bien.

Et je ne parle pas du ton condescendant de ton message. Je ne m'en formalises pas, mais rends-toi compte de ce point.

Edit : @nohar : J'avais bien vu le module ast, mais ça, c'est si je veux les utiliser en python. Il n'y a pas moyen de créer un générateur d'AST Python dans un autre langage ? Autrement dit, est-il possible de créer les AST et les stocker dans des fichiers sous une forme standard, pour que Python puisse les lire ?

Ce message va sans doute paraître agressif

Non juste condescendant, comme d'habitude.

Ce que tu dis est quasiment toujours parfaitement juste et justifié, par contre c'est systématiquement condescendant.

EDIT : Et oui pour la proposition de Dominus vous devriez partir là-dessus

Non. Ça doit être possible depuis l'API C, mais je n'ai jamais touché à ça.

Cela dit tu peux les écrire directement en python et les interpréter à coups de eval, ou bien coder rapido un petit code qui génère un AST depuis un dictionnaire de dictionnaires et de listes, ce qui te permettrait de les générer depuis du json ou du yaml.

PS : si vous voulez dans la journée je peux essayer de débroussailler un script qui fait ça, et vous le montrer pour vous aider à démarrer sur ces AST.

PPS : c'est pas con d'ailleurs, ça vous permettrait de coder facilement des tests unitaires pour votre parseur, et que chacun puisse bosser sur un parseur dans le langage de son choix, pour enrichir l'expérience. Si j'avais du temps j'aurais bien bossé sur un parseur en Rust pour me faire les dents sur ce langage.

Merci, je pense que je vais m'orienter vers la seconde solution, qui permettra à tout le monde d'utiliser mon "petit code" pour générer l'AST, et ainsi pourront s'occuper dans leur langage de générer le json/yaml.

Maintenant que ce détail d'ordre technique est réglé, je vais pouvoir mettre les mains dans le cambouis. Je commencerai à coder dès que j'ai le temps.

EDIT : Je m'occupe de créer le code de génération de l'AST à partir du json/yaml, sauf si quelqu'un d'autre qui s'y connaît mieux en python veut s'en occuper.

Je t'aiderai à le corriger au pire.

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

Par contre pour le code je suis pas encore sûr. A mon avis il faudrait coder en anglais parce que ça permet de donner des bases pour éventuellement aller plus loin, en lisant des documents en anglais (la communauté française a souvent des tutoriels moins complet que la communauté anglophone).

PS: Ce soir je recommente tout en français si vous êtes d'accord. Sinon j'ai une idée: pour chaque dossier on ajoute un fichier en markdown où on explique tout le code du package.