Acid, le lisp-like de la communauté !

Créons notre langage de programmation ! Pour le fun !

a marqué ce sujet comme résolu.

Reprise du dernier message de la page précédente

En fait, on est 3 contre 1, je suis plutôt d'accord avec les deux autres. :p

J'imaginais plus l'interfaçage avec d'autres langages comme un système de FFI.

De plus, je pense que c'est une très bonne idée de lancer des implémentations dans différents langages, et rien n'empêche de participer à plusieurs implémentations en même temps. Pour ma part, je vais lancer une implémentation en C++ (qui m'aime me suive :) ) et participer à celle en python.

Plus on apprend, et, euh… Plus on apprend.

+3 -0
Auteur du sujet

Dans ce cas, la majorité l'emporte :p

Est-ce qu'il est imaginable de donner une philosophie à notre langage ? Notamment au niveau de la syntaxe, d'avoir quelque chose d'intuitif (ie : plus dans les standard impératif que fonctionnel, de mon avis perso). D'ailleurs tu le montres bien dans ton poste Dominus, avec le if

Ricocotam

Je pense que c'est important en effet :)

"C’est nuageux par ici"

+0 -0

Cette réponse a aidé l’auteur du sujet

Dès que vous avez un compilateur qui fonctionne, je crée un compilateur zAcid sous zAcid. :D


Ce message est juste là pour dire que je vous suis, même si je ne sais pas encore trop si je vais participer. Je suis plus partant pour bosser sur la bibliothèque une fois les bases faites.

Hier, dans le parc, j’ai vu une petite vieille entourée de dinosaures aviens. Je donne pas cher de sa peau.

+3 -0

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.

+2 -0

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.

Édité par nohar

I was a llama before it was cool

+8 -0

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…

Édité par Gabbro

Hier, dans le parc, j’ai vu une petite vieille entourée de dinosaures aviens. Je donne pas cher de sa peau.

+4 -0

Je commenterai ça demain, merci de me le rappeler :P

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 :euh:

Édité par felko

Anciennement AlphaZeta

+0 -0

+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.

+5 -1
Auteur du sujet

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.

"C’est nuageux par ici"

+1 -1
Auteur du sujet

mais comment mettre à niveau tout le monde (surtout avec mes talents pas terribles de pédagogue) ?

AlphaZeta

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

"C’est nuageux par ici"

+0 -2

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 ?

Plus on apprend, et, euh… Plus on apprend.

+2 -1

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 :-)

Édité par Eusèbe

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 ?

mehdidou99

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.

Édité par nohar

I was a llama before it was cool

+4 -1

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 ?

Édité par mehdidou99

Plus on apprend, et, euh… Plus on apprend.

+4 -2

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

Édité par Javier

Happiness is a warm puppy

+8 -1

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 ?

mehdidou99

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. ;)

Édité par nohar

I was a llama before it was cool

+0 -0

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.

nohar

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.

Édité par mehdidou99

Plus on apprend, et, euh… Plus on apprend.

+0 -0

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.

Édité par felko

Anciennement AlphaZeta

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte