c’est un langage ayant à la fois des types statiques et des types dynamiques
Ok, donc le duck-typing n'est pas incompatible avec le typage statique. C'est tout ce que je voulais relever.
Concernant le sujet dans sa globalité, quand je lis des idées comme avoir un système de type statique inféré, un modèle objet, un style OO ou fonctionnel, j'ai vraiment peur. Car au fond, vous semblez ignorer la difficulté et le travail que peut demander ce genre de travail.
Un système de type statique inféré par exemple, c'est clairement difficile et il ne suffit pas de lire le dernier chapitre du LLC pour s’atteler à la question mais bien se taper le TAPL pour comprendre tout les détails (et comme on dit, le diable se cache dans les détails) et comprendre les tenants et aboutissants d'un tel programme. D'autant plus que ce dernier livre ne parle même pas d'inférence qui rajoute une complexité encore plus énorme et qui lui vaut un autre livre, le ATTAPL.
Paradigme fonctionnel ou objet, c'est la même. Le Modern Implementation of Compiler y mets du temps pour parvenir à ces notions et c'est pas en un week-end qu'on peut avoir une vision globale de tout les problèmes liés à l'implémentation de ces concepts (il faut attendre la partie II après le GC pour commencer à en voir les prémices).
Bref, pour peu qu'on est une certaine honnêteté sur ce que veut réellement dire le niveau débutant, je ne peux que vous conseiller de revoir ce vieux topic qui est exactement se que vous chercher (après, vous pouvez très bien reprendre le contenu, changer quelques détails, mais au fond, difficile à redire de ce topic) et ce cours de qualité sur l'implémentation d'un petit langage informatique en OCaml.
Ces derniers restent sur des idées très simple. Le premier utilise une syntaxe très simple qui peut être implémenter à la main ou à l'aide d'un outil comme flex/bison, il fait aussi totalement abstraction du langage que l'on peut utiliser (on peut s'amuser à le faire en C, d'ailleurs voici un très bon cours - en anglais - sur ce sujet) et laisse des questions ouvertes à la fin sur, justement, des concepts un peu plus difficiles à implémenter (dont le typage).
Le cours sur l'implémentation d'un langage en OCaml se concentre sur une syntaxe un peu plus évolué avec une notion de précédence (car la notion de précédence n'est pas simple pour un débutant) pour terminer sur une évaluation d'un petit langage impératif très simple. Et avec ces deux documents, on a déjà la base de se que peut être un langage sans pour autant attaquer des notions que d'autres documents externes expliquerons certainement mieux que nous tous.
Le point est surtout de prendre le lecteur par la main et de l'aider à bootstrapper son langage (aussi simple qu'il soit) afin qu'il puisse s'amuser ensuite avec en faisant, premièrement, ses propres choix (comme faire un langage fonctionnel avec un typage statique … ou non) et lui offrir une base lui permettant justement de pousser ses idées. Cela ne devrait clairement pas aller plus loin, autant sur l'idée du langage que sur les outils qu'il devrait utiliser. Il suffirait alors juste de pointer les documents nécessaires pour justement aller plus loin (comme je viens de le faire d'ailleurs).
Edit : Autant pour moi, je n avais pas compris
Pour l'idée du modèle OO fonctionnel, je comprends que ça puisse être super dur (en fait j'en sais rien, j'ai pas essayé). Par contre pour l'inférence de types, ça peut se faire assez facilement si on adopte un système de typage à la Hindley-Milner. Il existe des algorithmes déjà implémentés en Haskell comme l'algorithme W.
Sinon je veux bien utiliser OCaml, j'ai jamais essayé mais ça a l'air cool.
Après réflexion c'est vrai que ça serait mieux de partir sur un langage minimaliste comme l'a dit Dominus Carnufex, mais d'aller jusqu'au bout avec (implémentation d'un compilateur, optimisation, constant folding, etc…)
Encore une fois, faire des groupes pourrait régler le problème. Chacun, en fonction de ses compétences, veut faire ce qui l'arrange le plus ; ça fait trois pages qu'on débat sur la spécification du langage sans arriver à se mettre d'accord, et je vois mal comment on pourrait trouver un compromis.
En résumé, les plus "avancés" veulent du fonctionnel alors que cela fait un peu peur à des personnes débutantes, comme moi.
Étant donné que nous sommes nombreux à être intéressés par l'idée, il serait facilement possible de créer des groupes en fonction de ce que l'on souhaite accomplir et du niveau requis.
Sinon je veux bien utiliser OCaml, j'ai jamais essayé mais ça a l'air cool.
J'aimerais également découvrir.
Il est difficile de savoir que faire. Soit l'on essaye de faire une spec' générale du langage, mais l'on risque de partir dans des choses un peu trop ambitieuses, soit l'on y va progressivement, en réfléchissant aux différents aspects lorsqu'ils se présentent à nous. Par exemple, on travaille sur les opérations mathématiques, puis sur les variables, etc… Quand on tombera sur les variables, on pourra alors se poser la question du typages et tout ce qui va avec.
Toutefois dans ce cas, comme souligné plus haut, des problèmes pourraient survenir. Il faudrait alors revenir en arrière et revoir certaines petites choses, notamment au niveau de l'implémentation. Mais d'un autre côté, je ne doute pas qu'il faudra passer par plusieurs versions d'un implémentation avant d'avoir quelque chose de fiable.
De mon point de vue, je serais pour la deuxième solution, prendre les problèmes les uns après les autres. On peut notamment commencer par ce qui me semble le plus évident : les opérations mathématiques. Qu'en pensez vous ?
Voici le lien d'un livre qui pourrait vous aider: http://createyourproglang.com/ Il parait que c'est une bonne lecture.
Sinon, savez vous à quel usage servirait ce petit langage?
DominusCarnufex, Dinosaure a raison : les objets dans OCaml sont un très bon exemple d'un duck typing statique. On entend plus souvent parler de « typage structurel » quand c'est statique (parce que ça fait plus sérieux ?), mais ça désigne exactement la même chose (cela dit je ne comprends pas trop moi non plus pourquoi c'est cet article qu'il t'a donné.)
Il a raison aussi en disant qu'il ne faut pas sous-estimer la tâche : implémenter un langage complet, c'est dur. À mon avis, commencez par un petit langage impératif (avec un typage statique) simple, il sera toujours possible de rajouter des choses après (mais si vous arrivez déjà à un interpréteur complet pour un langage impératif avec des procédures, ce sera un réel succès). Un petit Lisp (avec un système de types simple), c'est aussi une bonne idée sur le papier, mais c'est probablement moins dans la zone de confort de ceux qui pourraient profiter du projet pour apprendre des choses, donc je suis moins convaincu.
Pour le langage d'implémentation, choisissez un langage expressif. Il y a un cours pas trop mal sur http://progmod.awesom.eu/tutoriel/10/interpreter-un-petit-langage-imperatif/index.html pour écrire un interpréteur pour un langage impératif très simple en OCaml si vous voulez (si vous partez sur Lisp, vous pourrez l'utiliser aussi, le cours consiste surtout à présenter les outils pour faire l'analyse syntaxique).
Si OCaml vous fait trop peur, il y a des trucs en Python pour faire de l'analyse syntaxique proprement (PLY, de mémoire). C'est dommage de se priver des outils des langages fonctionnels fortement typés pour manipuler les arbres et les structures riches qu'on rencontre quand on manipule des programmes, mais ça restera un meilleur choix qu'un Java (ANTLR, c'est relativement puissant, mais beaucoup trop compliqué) ou un C (la gestion de la mémoire, vraiment, vous avez autre chose à faire).
Ceci étant dit, vous pouvez aussi avoir plusieurs projets : certains auront envie de faire ça dans leur coin pour implémenter des idées à eux, d'autres auront trop peur de s'y lancer de but en blanc et préfèreront contribuer des petits trucs à quelque chose d'existant.
Dans tous les cas, c'est une très bonne idée. Espérons que ça marche, et n'hésitez pas à venir en parler ici souvent (surtout si vous faites ça en OCaml, ça nous changera un peu.)
Vous savez à quoi servira ce langage ?
À rien. Il ne faut pas espérer écrire le futur remplaçant du Python, c'est complètement hors de portée. Mais implémenter un langage (un interpréteur dans un premier temps, puis pourquoi pas un compilateur, peut-être en commençant par un langage cible relativement facile comme le C) est un excellent exercice de programmation, qui vous apprendra énormément de choses. Lancez-vous !
Si on ne sait pas un minimum ou l on va, on va droit dans le mur. Je pense qu il faut quand meme passer par une phase de specs, pour au moins definir le langage dans les grandes lignes, envisager les evolutions possibles…
<troll>Et pourquoi pas directement compiler en langage machine? comme ça, tout le monde part de zéro dans le domaine!</troll>
Sinon, je suis super intéressée par le projet.
au passage, je plussoie nedhidou99 pour sa dernière remarque, après avoir avorté trois projets pour cette raison.
Bon, redevenons un peu sérieux. J’ai bien conscience que tout le monde n’est pas familier des langages fonctionnels, et que vu de l’extérieur, ça peut paraître compliqué de s’y plonger pour créer un nouveau langage. Mais si je suggère un langage fonctionnel minimaliste à la Lisp, ce n’est pas pour rien (et pas uniquement parce que la syntaxe du Lisp rend l’analyse syntaxique beaucoup plus simple).
En effet, il est possible d’écrire un langage fonctionnel fort puissant et relativement simple d’utilisation (on ne parle pas d’un nouveau brainfuck, là) en manipulant très peu de concepts différents. Pour vous donner une idée, le Haskell est transformé par son compilateur en un « sous-langage » fonctionnel appelé Core, dont voici la spécification formelle.
Ne vous laissez pas effrayer par le côté très formel de la présentation, ce sont des concepts basiques qui sont utilisés. Et il n’est même pas nécessaire de tous les implémenter pour avoir quand même un langage qui marche ! Par exemple, les définitions locales (3e bloc, 6e ligne) peuvent être supprimées.
Pour ceux qui ne seraient pas très à l’aise avec les termes employés dans le schéma ci-dessus, voici à quoi peut se réduire un langage fonctionnel avec typage statique :
1, 42, 3,1416 ou encore 'k') ;Et voilà ! Pas de types paramétrés, pas de classes de types, pas d’inférence de types, pas d’évaluation paresseuse, pas de définitions locales, pas de tuples à champs nommés, etc. Tout cela pourra être rajouté plus tard, si le projet arrive jusque là.
Et même si le projet ne va pas plus loin que cette définition minimale, le langage permettra malgré tout de faire énormément de choses, et plus encore avec une bibliothèque standard écrite dans le langage lui-même.
J'ai pas lu toute la discussion mais je serais pas mal intéressé de participer au projet. Juste je pense que ça été dis mais le langage sera interprété ou compilé et en quel langage on compte faire l'implémentation ?
Ce que propose Dominus me plaît bien.
Après si certains préfèrent vraiment l'impératif, on peut faire deux langages. Du genre on fait deux équipes : une qui fait une version fonctionnelle, l'autre une version impérative. Le but du jeu serait de confronter les deux mini langage sur des exemples précis et on fait des comparaisons sur la simplicité d'écriture / la rapidité d'exécution etc. #TeamFonctionnel
Pour la peine sa fait un petit temps que je veux apprendre un langage fonctionnel donc en coder un m'intéresse pas mal. #TeamFonctionnel 
pour interprété ou compilé, je pense qu'il est toujours possible de faire les deux. Un compilateur qui transformera en code exécutable (pourquoi pas via un autre langage au choix) et un interpréteur. En ayant tout lu, je ne crois pas qu'il n'y ai donc eu de choix définitif sur ce point, et encore moins sur le langage utilisé.
@Dominus Carnufex, et pourquoi pas un mélange des deux (si c'est possible, car ça, je n'en sait rien).
J'hésite : #TeamFonctionnel ou #TeamImpératif ? C'est dur de choisir !
Et bien, je ne choisirai pas : #TeamFonctionnel et #TeamImpératif. Pourquoi ne pas participer aux deux projets ? 
Ce serait bien d'ajouter une touche d'originalité, comme l'a dit Gabbro. Pour l'impératif, il a déjà proposé l'orienté événements, et pour le fonctionnel, avez-vous des idées ?
De plus, ça serait amusant de développer le langage impératif avec un langage fonctionnel (OCaml), et le langage fonctionnel avec un langage impératif/OO (C++ ? 
).
Sinon, ça me plairait de découvrir OCaml (d'autant que je vais souvent l'aborder en prépa).
@mehdidou99 En prépa c'est le vieux Caml Light qu'on utilise. Il y a quelques nuances (et quelques petites choses insuportables accessoirement). 
@joseph : c’est possible, un certain nombre de langages le font, mais c’est loin d’être simple, forcément.
@mehdidou99 : à voir si c’est possible tout en restant simple, mais on pourrait intégrer le système de signaux de Elm. En gros, ça permet de signaler qu’une valeur est susceptible de changer sous l’action de l’utilisateur, et qu’il faudra recommencer les actions décrites avec cette nouvelle valeur. C’est un système original est étonnamment efficace pour gérer les événements.
Mais bon, soyons honnêtes, ça risque d’être brutal à intégrer.
Salut,
Je propose qu'on fasse un groupe Slack ou quelque chose du genre. Comme ça on s'aide tous sur le chan #general et parallèlement chaque team développe son langage.
Si j’atteins +5 je crée le groupe Slack, envoyez vos email en MP.
Edit: je compte pas les -1
Salut,
Je propose qu'on fasse un groupe Slack ou quelque chose du genre. Comme ça on s'aide tous sur le chan #general et parallèlement chaque team développe son langage.
Si j’atteins +10 je crée le groupe Slack, envoyez vos email en MP.
Sinon il y a le nouveau service de Framasoft framateam
Il y a 2 ans, j'ai écrit un interpréteur Lispoïde en OCaml à partir du tuto sur le langage impératif donné plus haut. Ça m'a franchement beaucoup plu, parce que:
Je vous conseille franchement de vous pencher sur l'implémentation d'un Lisp-like. C'est pas très difficile, on arrive rapidement à un résultat et surtout, pour ceux qui n'ont jamais fait de fonctionnel, ça peut être très très instructif. En plus, comme la grammaire est assez simple, vous pourrez apprendre plein de trucs à ceux qui connaissent pas sur les grammaires formelles, les expressions régulières et la notation EBNF sans les perdre. Et pour ceux qui en veulent toujours plus, vous pourrez vous pencher sur les subtilités de l'évaluation ou faire des macros.
Par contre, un système de types, ça va être coton. Implémenter un système de types du genre Hindley-Milner ça va pas être si facile que ça. Ayez pas les yeux plus gros que le ventre. Si vous pondez une spécification d'un Lisp-like et que vous codez ça vous aurez une base à améliorer. Si vous vous attaquez à trop gros, ce sont les très bons qui vont tout faire et y'en aura pas pour tout le monde, et ça va en dégoûter.
Au niveau du langage utilisé, si on compte le fait que dans ce topic il y a des gens qui n'ont jamais fait de fonctionnel, ça me paraît un peu chaud de faire ça en fonctionnel. Par contre, si vous choisissez un truc comme Python et que quand vous avez implémenté correctement une partie en Python vous faites un atelier retranscription en fonctionnel, ça peut être très très sympa.
Je m'étais basé sur la grammaire de Scheme R6RS en simplifiant. Ça peut être une bonne base. Il y a SICP aussi qui a de bonnes informations. Mon arbre syntaxique c'était juste ce type:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | type ast = form list type form = | Int of int | String of string | Identifier of string | True | False | Lambda of string list * form | VarDef of string * form | FunctionDef of string * string list * form | Quote of form | List of form list | Nil | If of form * form * form |
C'est déjà suffisant pour s'amuser.
Ok pas de groupe Slack 
Mais comment on va faire pour communiquer alors ? Surtout s'il y a plusieurs team…
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
