Je cherche un associé pour créer un langage de programmation, ma motivation est de m'exercer.
Version imprimable
Je cherche un associé pour créer un langage de programmation, ma motivation est de m'exercer.
Il y a quelqu'un?
Bonjour,
Oui, il y a bien quelqu'un puisque la liste des sujets du forum assembleur indique qu'à l'heure où j'écris, ton fil a été affiché 46 fois déjà. En revanche, avec un message aussi laconique, tu ne risques pas d'obtenir beaucoup de réponses. Un langage est avant tout formel. Son implémentation dépend ensuite des différentes machines sur lesquelles il est amené à être utilisable.Citation:
Envoyé par Houllad
- Quel est l'objectif visé par ce nouveau langage ? Usage général ? Spécifique comme Matlab ? Autre ?
- Doit-il être compilé ou interprété ?
- As-tu des notions de langage formel ?
- Qu'attends-tu de ton « associé » ?
… et surtout, dans le domaine qui nous concerne :
- Est-ce que ton projet concerne l'assembleur de près ou de loin (par exemple pour écrire son compilateur) ?
Merci de la réponse, j'ai un niveau intermediaire en assembleur x86 syntaxe Nasm, j'ai déjà quelques notions sur la théorie des langages, j'ai déjà implémenté un compilateur 16 bits pour un langage que j'ai créé, je le nomme MPL (Mon Petit Langage).
Concernant le langage à créer rien n'est décidé quand à la syntaxe ou la plateforme cible.
Le mieux dans ce cas est de commencer à développer ton projet pour voir où il te mène (parce qu'avant cela, tu auras du mal à laisser quelqu'un d'autre y mettre les doigts). Lorsque ton projet sera suffisamment développé pour que cela devienne un travail routinier de ton côté, tu pourras le mettre en ligne et éventuellement bénéficier d'un hébergement. Quelques projets similaires sont déjà hébergés sur notre site.
Bon. Et c'est un langage qui est censé servir à quoi ? Si tu n'as pas la réponse à cela non plus, ça va devenir difficile de t'orienter. Essaie déjà de tirer cela au clair puis de vérifier, ensuite, s'il n'existe pas déjà un langage similaire répondant à ces besoins car autrement, tu risquerais de te rendre après plusieurs mois que tu as travaillé pour rien.Citation:
Concernant le langage à créer rien n'est décidé quand à la syntaxe ou la plateforme cible.
Concernant votre dernière suggestion, mon objectif n'est pas de créer un langage "révolutionnaire", mais c'est juste pour l'entraînement, l'acquisition de "compétences" dans ce domaine.
Soit, c'est une bonne chose.Citation:
Envoyé par Houllad
Si c'est juste pour le principe, alors il s'agira principalement de langage formel. Tu peux t'exercer avec Lex & Yacc, par exemple, pour tenter de dresser une grammaire qui ne soit jamais ambiguë. C'est la principale difficulté des nouveaux langages. La suivante consiste à s'assurer que le langage que tu es en train de définir permettra bien s'exprimer tout ce qui sera possible de faire dans le cadre que tu as défini et ce n'est pas une mince affaire. Il ne s'agira pas simplement d'ajouter de nouveaux mots-clés. L'exemple-type est celui du SQL qui a tenté de formaliser toutes les opérations que l'on faisait déjà jusqu'ici avec les fichiers, ainsi que les différentes contraintes d'intégrités implémentées jusque là sans norme strictes.
Concrètement, tu veux faire quelque chose qui ressemble au Basic ? Au logo ? Au C ? Au Python ? Au SQL ?
Est-ce que tu veux faire un langage interprété, avec un mode direct dans lequel chaque mot-clé saisi par l'utilisateur serait immédiatement traduit en une action, ou un langage compilé comme le C ou l'assembleur, permettant de produire un exécutable en langage machine ou dans un bytecode quelconque ?
celui que j'ai déjà créé (MPL) est un langage compilé qui ressemble au C (dans la syntaxe), son compilateur écrit en assembleur 16 bits produit des exécutables MS-DOS, celui-ci a de sérieuses limites, par exemple il ne gère pas les nombres à virgule, impossible de définir un tableau, etc.
Dans ce nouveau langage, je pense que je vais juste améliorer le précédent en introduisant de nouvelles fonctionnalité, je pense même passer dans un langage multi-plateforme pour l'implémentation du compilateur.
Bon, tu n'es pas dans la case "grand débutant". Mais comme l'a dit Obsidian, il faut quand même se fixer un cadre, et des objectifs qui avancent par paliers.
Si tu veux tenter de faire un langage généraliste, fais déjà un tour de ceux qui existent et et sélectionne ceux avec lesquels tu te sens des affinités. Après, tu pourras définir des étapes de développement. En première approche, je pensais d'une part à quelque chose comme le Pascal (type Turbo Pascal 3.0), car tu auras des contraintes "simples" à vérifier. Tu n'est pas obligé de gérer les appels de fonctions/procédures ni les types de structures dans un premier temps (en parlant d'étapes). Il y a aussi d'autre part une famille sympa pour y aller par paliers : le Lisp, avec sa gestion de base, puis piocher dans la liste des recommandations.
Par contre, avec "multi-plateforme" je pense que tu vises une autre activité : avoir ton compilateur disponible sur plusieurs processeurs, donc des assembleurs différents, et même des OS différents. Si tu veux le faire en parallèle du précédent, genre j'ajoute une petite "feature" à mon langage sur un environnement et ensuite je l'ajoute sur les autres, tu auras beaucoup de problèmes à gérer sans que globalement tu ais l'impression que cela avance. Ce qui peut se révéler démotivant. C'est toi qui vois…
Je suggèrerai de te concentrer sur un langage et de le développer le plus possible, de l'étendre. C'est là que tu apprendras le plus à la fois en théorie des langages, et en compilation. Déjà, il y a de la lecture à faire.
Bonne route !
@AdmChiMay, merci !
Je reprends un peu, sur la base d'un "mode Pascal". L'avantage est que tu peux compiler, et indiquer à la volée au numéro de ligne près où est l'erreur qui stoppe l'exécution. Tu peux repartir de ton existant. Des exemples d'étapes ci-après, l'ordonnancement des étapes n'étant pas imposé (à toi de voir/choisir).
- Reconnaître dans un fichier la déclaration du programme principal.
- Reconnaître les afficher le numéro de ligne où il y a une erreur.
- Reconnaître les déclarations de procédures et de fonctions (avant le "main").
- Être capable de suivre les fichiers inclus, déclarés en premiers (on compile toujours à partir du fichier qui contient le main). Et donc les déclarations qui s'y trouvent et dans ce cas, certaines sont locales à ce fichier et non visibles depuis le fichier du main).
- Quels types d'objets souhaites-tu être capable de traiter ? Là, il ne faut pas tout attaquer d'un coup, et savoir dans quelles limites on traite.
- Tu travailles avec des entiers, mais as-tu plusieurs types d'entiers ? P.ex. l'octet, l'entier "normal", l'entier "long". Sais-tu traiter les débordements ? Si tu fais une division, y a-t-il passage obligé vers un réel ?
- Mêmes questions pour les réels.
- Les deux points suivants posent le problème du changement de type : l'autorises-tu ? dans quelles conditions ?
- Les chaînes de caractères, comment comptes-tu les traiter ?
- Les tableaux ?
- Les listes ?
- Les pointeurs ?
- Les structures ?
- Les "if", avec combien de "else" possibles ?
- Utiliser le "case" pour les éviter des "else" en cascade ? avec quelles capacités ?
- Les boucles, plusieurs formes possibles (for, repeat, until) ?
- Le for, avec ou sans indice ?
- D'autres types ? P.ex. les nombres complexes (complexes d'entiers ? de réels ? ), les fractions, etc.
- Souhaites-tu inclure une notion d'objet ?
- Pour tes procédures et fonctions : types de retour autorisés ? Les paramètres sont de quels types possibles ? Si on les modifie dans la procédure/fonction, est-ce visible de l'extérieur ou pas ? dans quelles conditions ? (la déclaration "var" en Pascal).
- Les fichiers.
- L'interaction avec l'utilisateur : en mode console ? Quand essayes-tu de passer en ihm ? Il faudra peut-être mieux appeler une librairie dédiée (mais "simple" à aborder), p.ex. une appelable depuis du C (Tk de tcl/tk, IUP, Agar , et plein d'autres, je fais exprès de ne pas aller jusque Qt).
Tu verras, aborder une question amène plein d'autres questions (effets dominos en pagaille assuré :mrgreen:). Il faut donc à chaque fois ne pas vouloir en faire trop, poser clairement les limites, ce que l'on fait maintenant et ce qui sera à étendre "plus tard"). En version dite très simple, cela faisait (fait encore ?) un projet de L3 à mener en groupe sur 6 mois, avec les cours en parallèle qui abordaient les différents points.
Il sera intéressant que tu aies un accès à une BU, au moins pour aller lire sans forcément pouvoir emprunter. On y trouve des livres pas mal pour explorer, quitte à les acheter sur eBay ou Amazon ensuite (attention, beaucoup qui ne se font plus ont des prix qui varient selon la saison de 3€ à 50€ !). Tu peux trouver tes solutions seul, mais la lecture sur le sujet peut se révéler intéressante quand même (et même si tu fais à ta sauce, mais au moins tu sauras encore mieux pourquoi tu le fais).
Bon, vas-y tranquillou, car il vaut mieux ne pas se prendre la montagne de face.
Mon langage implémente déjà les mots-clés suivants:
Type de donné:
-Octet (1 byte)
-Mot (2 bytes)
-Chaine (max 128 bytes)
structures de contrôl:
-Si (if du C)
-Sinon (else du C)
NB: possibilité de combiner les deux pour faire un "sinon si"
-tant que (while)
autre:
-ret (return du C) j'ai choisi ce mot-clé pour rendre hommage à l'assembleur (j'ai implémenté le compilateur en assembleur)
-export: permet d'exporter une fonction.
-possibilité de référencer une variable.
PS: mes mots-clés sont en français parcequ'en réalité MPL n'est pas mon premier langage, il a évolué d'un autre, PLF (Programmation en Langue Française). Doc ici 8-)
Voici un programme complet qui demande un nombre à l'utilisateur puis affiche la factorielle de celui-ci
#inclure <MPL.INC>
mot fact (mot n)
{
si (n <= 1) ret 1ret n * fact (n-1)}
mot main (chaine cmdLine)
{
mot nscan ("%l", @n)mot result = fact (n)print (toString (result))
ret 0}