Ah mais je suis ravi d'apprendre que de ton côté tu as aussi avancé Peux-tu nous en dire un peu plus ? Je pense que c'est bien pour tous que chacun raconte un peu l'avancement de son implémentation au fur et à mesure
Je viens de faire une PR sur le dépôt avec la version 1.0 définitive de la spec d’Acid et du code d’exemple. Voici les changements apportés par rapport à ma proposition de plus haut.
Le type des lambdas avec des flèches devient du sucre syntaxique, et la proposition d’utiliser plutôt un type (lambda Char Char Bool) comme syntaxe de base est adoptée.
Le type fictif IO est abandonné. De même, putchar et main ont désormais pour type (tuple), et getchar a pour type Char. Le mot-clé req ne sert plus à rien, et seq devient une fonction de la bibliothèque standard.
Le type Int représente des entiers de n’importe quelle taille, ainsi que suggéré par Kje.
Comme demandé, la syntaxe de sucre syntaxique pour les listes abandonne les virgules : on n’écrit plus [1, 2, 3] mais [1 2 3].
La règle 30 a été ajoutée, car je l’avais oubliée dans la première version, alors même que je l’utilise dans le code d’exemple.
S’il y a des points de la spec que vous ne comprenez pas, des concepts qui vous paraissent bizarres, ou des choses dont vous ne comprenez pas la justification, n’hésitez pas à poser des questions, surtout les débutants. Ce sera plus simple pour moi que d’essayer de faire une explication détaillée de l’ensemble de la spec.
J'ai une petite remarque sur le int. Je sais que c'est moi qui l'ai proposé mais je me demande, finalement, si c'est une bonne idée. En pratique je trouve le principe cool (c'est bien pratique en Python) mais je m'interroge sur quelques points :
est ce que ça a un sens dans un langage typé statiquement ? Car c'est une donnée dont le format réel va changé au cours du temps.
est ce que si on le conserve, on peut utiliser le pattern matching pour en déduire le type sous-jacent ?
enfin j'ai peur que ce soit un peu tricky pour un langage censé être d'apprentissage. En Python pas de soucis mais dans un langage comme le C++ ça va demander de vérifier l'overflow à chaque opération pour potentiellement agrandir le type sous-jacent.
Cela pourrait être implémenter comme un type BigInt dans la bibliothèque standard… Ainsi, le langage n'a pas besoin de le supporter, mais il reste quand même possible de l'utiliser…
est ce que ça a un sens dans un langage typé statiquement ? Car c'est une donnée dont le format réel va changé au cours du temps.
Cela correspond au type Integer du Haskell, qui est utilisé sans difficulté et de manière totalement transparente par l’utilisateur final. C’est en sous-main que la taille réelle change, mais pour l’utilisateur, le type n’a pas de taille.
Cela se traduit par le fait que ce type est une instance de Bits, la classe de type qui permet d’utiliser les opérations bit à bit, mais pas de FiniteBits, qui nécessite que le type soit borné.
est ce que si on le conserve, on peut utiliser le pattern matching pour en déduire le type sous-jacent ?
Je ne comprends pas trop la question. Sur les types natifs, le filtrage par motifs ne peut être utilisé qu’avec des valeurs, car ils n’ont pas de constructeur.
enfin j'ai peur que ce soit un peu tricky pour un langage censé être d'apprentissage. En Python pas de soucis mais dans un langage comme le C++ ça va demander de vérifier l'overflow à chaque opération pour potentiellement agrandir le type sous-jacent.
C’était un peu une de mes réticences, mais il existe des bibliothèques qui font ça très bien, comme GMP, qui est portée dans des tas de langages. Par exemple, le type Integer de Haskell sus-mentionné s’appuie en sous-main sur GMP.
Personnellement je soutiens l'idée de garder le type Int générique de taille arbitraire – et je sais que c'est vicieux – parce que j'accorde une très grande importance à la différence entre typage et niveau d'abstraction.
Acid se veut un langage à haut niveau d'abstraction et fortement typé. Il faut être cohérent : dans n'importe quel langage de ce style, on se fout totalement de ce qui se passe sur le sillicium, on manipule des fonctions comme des objets de premier ordre, on compose, on lambda-ise, on fait de la récurrence, on ne manipule pas de pointeur, malloc est juste un mot étranger, on ne différencie pas la pile et le tas… Donc typiquement un entier doit être un entier : à ce niveau d'abstraction, un entier builtin doit être un entier, pas un byte ni un char ni un word ni un double word mais juste un nombre entier. La coertion explicite vers des entiers de taille fixe devrait au mieux être gérée dans la bibliothèque standard (comme le module struct en Python).
Certes ça va être bonbon à implémenter dans un compilateur natif, mais c'est le jeu, et le prix à payer pour avoir un langage cohérent.
En relisant la spec je me suis fait les réflexions suivantes :
les sucres syntaxique optionnels risques de faire un sacré bordel. Chaque implémentation va en avoir une partie mais pas forcément toutes. Du coup ça sera compliqué de savoir ce qui peut être utilisé dans les différentes implémentations et de se partager les codes de tests pour comparaison. Ne serait-il pas du coup plus pertinent d'imposer deux versions possible : acid avec tout ce qui est obligatoire et (nom temporaire) acid++ qui contient en plus tout ce qui est dans les sucres syntaxique. En gros deux versions différentes mais pas de choses optionnels.
il faudrait probablement définir clairement les opérations supporté nativement et leurs caractères. En gros à part l'addition qui est utilisé dans la spec on ne sait pas si on doit implémenté la soustraction, la puissance, les opérations sur les bits, etc. Et on ne sais pas non plus leur identifiant (la puissance par exemple est ^ dans certains langages et ** dans d'autres).
C'est vrai, on peut simplement faire un versioning commun : viser les fonctionnalités de base pour la 1.0, et le sucre syntaxique optionnel pour la 2.0, par exemple.
C'est vrai, on peut simplement faire un versioning commun : viser les fonctionnalités de base pour la 1.0, et le sucre syntaxique optionnel pour la 2.0, par exemple.
Et commencer par implémenter ces « fonctionnalités de base » (en fait, la plupart sont déjà probablement trop compliquées) avant de tirer des plans sur la comète pour la suite ? Ça me paraît être une excellente idée
Et commencer par implémenter ces « fonctionnalités de base » (en fait, la plupart sont déjà probablement trop compliquées) avant de tirer des plans sur la comète pour la suite ? Ça me paraît être une excellente idée
Ah, oui, et j'oubliai : tu peux la boucler ? Parce qu'à part être condescendant, tu n'as pas non plus été le plus actif pour faire avancer le projet. Je suis resté courtois au début, mais il ne faut pas exagérer. Alors va faire chier le monde sur un autre sujet.
Connectez-vous pour pouvoir poster un message.
Connexion
Pas encore membre ?
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
