Bonjour,

Tout est dans le titre, j'ai eu l'idée d'un language de programmation centré sur les Scopes, très flexible, avec des messages d'erreur compréhensibles, un language idéal pour débuter en somme.
Voici un bout de code,imaginé.
http://pastebin.com/Awxegvhm
Mais je ne sais pas quoi intégrer dedans, alors pourriez vous me donner une liste de choses qu'un language DOIT avoir ?

Niveau des choses que je prévois d'implementer en prioritée :
Les fonctions de bases d'I/O, les boucles, comparaisons, les IF/Else If/else,
les scopes et leur gestion, les variables globales et internes, les arrays

Plus tard : ( Seconde version)
Gestion de l'importation de ficheirs séparés
Surcharge de méthodes
Détailer la librairie standart
Ouvrir spark aux suggestions

Alors ? en théorie, je peux le faire, j'ai toute la structure de A à Z en tête, en théorie..

Hum... Tu fais ça pour le fun et l'experience, ou tu comptes l'utiliser ?

Sur tes prints, quel est l'interet du end1 ?

Si tu comptes vraiment t'investir dedans, tu devrais tout mettre en anglais (code et commentaire).
Comme ça, le jour ou tu voudras l'ouvrir aux contributions externes, tu n'auras pas besoin de repasser partout ou il y a du francais pour le remplacer par de l'anglais.

Salut,

Je sais pas quel est ton niveau de formation vis à vis des sciences informatiques et la théorie des langages, alors je vais rester assez vague.
Déjà, ce que ton snippet ne montre pas, c'est toute la réflexion sur ton système de types. On voit qu'il est statiquement typé, mais on en sait pas plus. C'est pas forcément important que ça ressorte dans la syntaxe du langage (encore que, avec les théories "poussées" sur les systèmes de types, il est possible de faire des typages qui s'auto-documentent dans le code, par exemple les systèmes des langages ML et dérivés (Haskell, Ocaml, Idris, ...) ou Scala), mais le strict minimum c'est que tu saches, toi, de ton côté, quelles garanties ton système de type enforce.

Déjà, le langage est orienté pour être compilé ou interprété ? Hybride avec du JIT, peut-être ? C'est un détail d'implémentation (ton langage ne devrait favoriser ni l'un ni l'autre ; une implémentation quelconque le fera, typiquement la première implémentation que tu feras déterminera la nature "par défaut" du langage, mais ça reste une facette), mais ça a une importance sur le comportement du système de types. Un langage interprété avec un typage fort peut offrir moins de garanties qu'un langage compilé avec analyse statique, et doit donc imposer moins de contraintes sur l'utilisateur.
Dans la même veine, définir le paradigme et les caractéristiques de ton langage éclaircira beaucoup de choses, parce que des concepts ou algorithmes ne sont pas compatibles (ou difficilement) avec certains (les algos d'inférence de type à base de lambda calcul ne sont par exemple pas très compatibles avec les langages objets).

Toujours dans le principe des types, il faut définir clairement ce qui est disponible. Ton langage permet-t-il à l'utilisateur de définir ses propres types ? Sous quelles formes (classes, prototypes, interfaces, contrats, types de classes, types de données algébriques, ...) ? S'il le permet, les types "de base" que l'on voit comme "string" ou "float" sont-il des primitifs, ou des types implémentés à partir du mécanisme de création de type du langage même ?

D'un point de vue comportement, le typage est-il flexible ou stricte ? C'est dépendant de la question du haut, parce que la flexibilité du typage dépend forcément des moyens de définition de type (si tu n'as aucune relation de types, ton typage est forcément moins flexible). Typiquement, il faut te demander ce qu'il se passe si un utilisateur donne un entier à une fonction qui attend un flottant : le compilateur rejette l'appel ? On a une coercition automatique sans perte ? Et si on a l'inverse ? Le compilateur fait-il une coercition automatique avec pertes cette fois-ci ? La flexibilité des types est basée sur des règles arbitraires à part ? La notion de perte de données ? Et pour les types créés par l'utilisateur (si c'est possible) ? Et ainsi de suite.

En se basant sur tout ça, tu peux te demander si ton langage est réflexif ou non. Comment les types sont-il gérés lors de la compilation et de l'exécution ? On a un effaçage des types lorsque le checker pense que tout est en ordre ? On garde des tags au runtime pour autoriser la réflexion ? Etc...

Donner un système de type à un langage, c'est vraiment pas mal de boulot. Il faut que tu définisses clairement toutes ces questions (et plus), parce que sinon ça risque d'être bancal et incohérent. Et si c'est pas juste un langage jouet que tu fais pour apprendre, il faut alors te renseigner sur les dernières théories, histoire d'apporter quelque chose plutôt que de rester dans un système de type qui aide autant le compilateur que l'utilisateur, type C/C++/Java.
Et c'est un point parmi tant d'autres que j'ai voulu approfondir (c'est surtout un des points les plus délicats du design de langage), mais il faut avoir la même démarche pour toutes les caractéristiques de ton langage.

D'une manière générale, j'ai du mal à voir ce que ton langage apporte. C'est très proche du C++ sur le peu qu'on a vu, et le système de scopes est simplement un système de modules/packages/namespaces, comme disponible à peu près partout. Tu as d'autres exemples à montrer ?

centré sur les Scopes

Qu'est-ce que tu entends par "scope" ? Ce mot a déjà un sens en programmation, ça n'a pas l'air d'être ce dont tu veux parler. D'après ton bout de code ça ressemble à de genre d'objets ou de modules que l'on peut ouvrir pour pas avoir à réécrire tout le temps son nom. Pourquoi pas, mais d'une part, ça existe déjà dans pas mal de langages, et d'autre part, c'est pas vraiment suffisant pour en faire un "nouveau" langage, tout le reste de ce que tu as écrit est juste du c++.

très flexible

Tu as quoi en tête ? Il pourra faire quoi que les autres langages n'ont pas, en quoi ces features sont importantes, et comment vas-tu les implémenter ?

avec des messages d'erreur compréhensibles

Encore une fois, comment vas-tu t'y prendre pour que tes messages d'erreurs soient plus compréhensibles que ce qui se fait dans les langages actuels ? Ça impliquerait de mieux détecter où sont les erreurs.

pourriez vous me donner une liste de choses qu'un language DOIT avoir ?

Des fonctions de première classe et lambda-expressions, un garbage collector, des objets/modules, la tail-optimization pour la récursivité, un bon système de types (avec inférence), des structures de données avancées, et surtout, des bibliothèques très complètes et bien documentées

Je pense qu'il te manque un peu d'expérience pour te lancer la dedans, essaie de tester d'autre langages de programmation et d'autres paradigmes pour te faire une idée.
De plus, si tu as une vision "long terme" de ton projet, oublie pas que tu vas devoir commencer avec du très basique (et c'est déjà pas si simple) et enrichir au fur et à mesure.

Commence déjà par un truc qui sait faire créer des variables de base (int, float, string)
Si tu sait faire un interpréteur ou un compilateur qui sait faire :
Int i = 3
print i
//affiche "3" (la syntaxe importe peu)
ça serait déjà bien

Mais, j'ai pas dis vouloir faire un truc pro'
C'est plus pour le fun, et oui j'empreinte un peu la syntaxe du C++, mais je n'espère pas du tout m'en rapprocher
C'bien de tuer des idées dans l'oeuf

et Dark, j'ai déja commencé avec cela, si je veux me lancer la dedans c'est car j'ai envie de passer à la vitesse supérieure, j'ai déja même créé un compilateur d'instructions mathématiques

Au niveau du système de scope, il est semblabe à celui des Namespaces en c++ mais il est indispensable disons ^^

Et l'utilité du Endl, certes.
Quel est l'utilitée d'un endl en c++ aussi? Il fait la même chose qu'un \n

Ah et j'ai oublié de présenter la fonctionnalité :
Les hooks, on peut intégrer sa fonction dans le language, pour l'utiliser dans son jeu par exemple, comme le lua ^^

Disons que je veux plus me rapprocher du Lua que du C++

Encore un langage

J'veux pas détruire tes espoirs mais visiblement t'as pas les connaissances requises pour faire quelque chose ni même pour avoir les bonnes idées concernant la conception d'un langage.

Ça pourra pas aller plus loin que le fantasme à moins d'étudier une tonne de choses théoriques mais tout le monde a déjà expliqué ça avant moi.

Le 13 septembre 2015 à 00:08:30 BonbonMagique a écrit :
J'veux pas détruire tes espoirs mais visiblement t'as pas les connaissances requises pour faire quelque chose ni même pour avoir les bonnes idées concernant la conception d'un langage.

Ça pourra pas aller plus loin que le fantasme à moins d'étudier une tonne de choses théoriques mais tout le monde a déjà expliqué ça avant moi.

Ce que tu comprends pas c'est que ça doit faire 1 an que je fais des recherches sur le sujet. je sais ce que je fais ,j'ai déja toute la structure théorique de l'interpréteur en tête (et une partie en code). Le plus gros danger pour moi est la flemme

La j'ai déja implémenté les variables,:
Int & Array Int
Float & Array Float
String & Array String
Char & Array Char
Pointeur

La je commence le Lexer (j'en ai déja fais des dizaines donc c'est izi bien que très pompeux à écrire (surtout la partie indentification, qui est simple mais très longue ))
Apres j'arriverais à la définiton complète de la grammaire du language afin d'aborder la problématique de l'AST. (Combien de types de noeuds dois-je créer et comment fonctionneront t-ils)

Enfin après si c'est pour le fun pourquoi pas.

Salut, très intéréssant

J'ai été très intéréssé par la création de langage de programmation...j'ai acheté 2 grosses références sur le sujet mais mon dieu, ça m'ennuyait à mort.
Du coup j'ai abandonné.

Enfin bref bonne chance.
Que la flemme guide tes pas.

Le 13 septembre 2015 à 00:17:41 pierre135b a écrit :
Apres j'arriverais à la définiton complète de la grammaire du language afin d'aborder la problématique de l'AST. (Combien de types de noeuds dois-je créer et comment fonctionneront t-ils)

Le problème avec une grammaire type C++ c'est pas le lexer ; un lexer top-down des plus basiques suffit pour la plupart des grammaires, et les points de difficulté sont souvent orientés vers des features que ton langage n'a pas, comme l'indentation significative (Python) ou l'interprétation par layouts (Haskell).
Là où ça va être difficile, c'est avec le parseur. Là encore avec la grammaire que tu as donné on en sait pas trop sur l'étendue de ta syntaxe (tu n'as pas définie de grammaire standardisée en (E)BNF ?). Le problème avec les grammaires du même type que C++, c'est qu'elles sont ambigües sans table de symboles (simulation d'un contexte dans une grammaire hors-contexte), et non-déterministes sans lookahead potentiellement infini. Il te faut donc au minimum un parser de type LL(k) (je pars du principe que tu construis le parser à la main) si tu contrains ta grammaire, un parseur régulier LL(*) si non. Et ça, en plus de compliquer l'implémentation, ça apporte un monstrueux problème de performance qu'il faudra régler par exemple en ajoutant de la mémoïzation à ton parser (et donc regarder du côté des parsers packrat).

Vu comment tu parles des types de noeuds je présume que tu es déjà parti sur un AST hétérogène, et vu que tu parles de leur comportement, sur un "marcheur" intégré ? Le choix me semble un peu prématuré étant donné que tu n'as pas encore de grammaire complète ; les marcheurs intégré sur AST hétérogène sont les plus "innés" et les plus faciles à mettre en place, mais il sont très vite limités.

Du coup voilà, si tu t'es renseigné sur toutes ces théories c'est très bien ; simplement en te lisant, on a quand même l'impression que tu vas trop vite, directement à l'implémentation. Je me répète, le but n'est pas de te miner, juste de te guider un peu. Un langage typique sans nouveautés révolutionnaires, c'est relativement facile à mettre en place. Les théories et leur mise en pratique sont là depuis des décennies, les problèmes de lexer, parser, analyseur statique et générateurs de code/interpréteur sont des problèmes quasiment réglés depuis longtemps (ça n'empêche pas d'en faire un sujet complexe avec beaucoup de notions à appréhender). Si on insiste beaucoup sur la partie design, c'est justement parce que c'est ça, le véritable travail de création d'un langage. Avant même d'attaquer une ligne de pseudocode, tu devrais avoir un plan précis de ton langage, ses caractéristiques, son fonctionnement détaillé, et sa grammaire dans un format standard.

Si le but est seulement d'apprendre la création de compilateurs, alors créer un langage sur lequel t'entraîner est inutile, parce que tu ne te focalise pas sur les points intéressants de la création d'un langage. T'entraîner à implémenter des langages aux spécifications déjà créées sera bien plus formateur.
Si par contre ton but est d'apprendre à designer des langages d'abord, et à les implémenter ensuite, il faut sortir un peu de cette implémentation dans un premier temps, et te concentrer sur tous les points qu'on a évoqué plus haut.

Le 13 septembre 2015 à 03:26:30 absorbement a écrit :
Salut, très intéréssant

J'ai été très intéréssé par la création de langage de programmation...j'ai acheté 2 grosses références sur le sujet mais mon dieu, ça m'ennuyait à mort.
Du coup j'ai abandonné.

Enfin bref bonne chance.
Que la flemme guide tes pas.

Oui, si tu n'as pas fait d'études le Dragon Book est un peu beaucoup très dur à lire

Et VDD:
La grammaire je vais la définir justement, mais je vais la garder simple et compréhensive. je sais pas si j'utiliserais BNF mais plutot un truc simple que j'écrirais mais qui s'en rapprochera.
Genre :
Comp : var | const == var | const
: var | const >= var | const
Ce qui veut dire qu'une comparaison est constituée de, par exemple :
Left (une variable ou constante) Operator(==) Right(une variable ou constante)

Niveau de l'AST je sais déja exactement comment je vais procéder, pas de soucis à ce niveau ^^

Juste une note sur les notations : si on a des formats standardisés, c'est souvent pour une raison. La BNF est simple, mais surtout la plupart des techniques d'unification et simplification de grammaires sont basées sur une notation de ce type. Si tu pars sur une notation arbitraire qui ne réutilise pas les bases du format, tu risques d'avoir plus de mal à appliquer les techniques traditionnelles pour simplifier ta grammaire une fois que tu as un premier jet.

Le problème que je vois avec ton format, c'est que tu ne sépare pas les symboles terminaux des non-terminaux ; le format est lui-même ambigu, ce qui est un peu le comble pour un format de grammaire formelle
Pourquoi "var" serait traité comme un symbole non terminal alors que "==" serait traité comme un symbole terminal ? Les deux sont nus (sans quotes autour), ils devraient avoir le même comportement.

Autre point, celui-ci s'applique par contre à ta compréhension des formats de spécification de grammaires plutôt qu'à ton format (tu aurais eu le même soucis avec du BNF très certainement) : ta clause "comp" est alternée inutilement. Plutôt que de spécifier tous les opérateurs binaires en notation infix un à un, alors qu'ils sont tous de la forme <lhs> <op> <rhs>, tu ferais mieux de définir ta clause comme ça, avec <op> un symbole non terminal qui se résout, par exemple, en "==" | ">=" | "<=" etc... De cette manière, tu as une clause simple factorisée, déterministe seulement avec un lexème d'avance. Ta clause précédente demandait du backtracking, parce que dans le cas d'une opération binaire correcte quelconque, on a de la consommation de lexème dans tous les cas, alors qu'un seul opérateur (une alternative de ta clause) est acceptable.

Je vais regarder BNF, mais bon j'aime pas quoi

Juste pour vérifier, une condition en BNF ça serait, par exemple :
<term> ::= <constant> | <string> | <declarator>
<condition> ::= <term> "==" <term>
<if_statement> ::= "if" "(" <condition> ")" "{" <statements> "}"

?

Je programme depuis plus de 30 ans maintenant, et je pense pas qu'un language "doit" voir des fonctionnalité ou non!

En fait la création des languages répondais a une problématique donné.

Demande toi ce que tu voudrais programmer avec et ajoute donc les fonctions voulus!

C'est comme ça que j'ai fait mes lagunages pour la reconnaissance automatique de document, ou pour des petits jeux avec IA