Re: Un nouveau langage

Salut

Vu qu'XML semble adapté dans ton cas mais trop verbeux, tu ne veux pas
utiliser YAML. Ton exemple ressemble furieusement à une déclaration en YAML
je trouve

A+
Seb

Le 2 septembre 2010 13:24, Jean-Baptiste BRIAUD -- Novlog <
[email protected]> a écrit :

> Bonjour à tous,
>
> Après une période d'expérimentation et de consolidation de notre
> innovation,
> nous ouvrons le chantier d'une version textuelle de notre langage.
> Pour moi, c'est un retour aux sources car j'ai commencé par une version
> textuelle il y a quelques années.
>
> Bref, je voulais partager avec vous au début de ce chantier quelques
> options pour ce langage et avoir votre avis.
> Toute les suggestions sont les bienvenues, même si en apparence elles
> semblent saugrenues  :-)
>
> La syntaxe générale sera de type C/Java/Javascript.
> Un grand classique et une justification qui n'a pas changé : tout le monde
> la connait cette syntaxe.
> L'effort d'apprentissage sera donc en principe simplifié.
> Inconvenient : çà n'est pas une syntaxe générique comme XML ou LISP.
> Cela peut aussi être perçu comme un avantage par certains :-)
>
> Donc, nouveau concept = nouveaux éléments de syntaxe, contrairement à XML
> par exemple :
> <personne name="blabla"/>
> Si on souhaite ajouter un prénom, c'est simple :
> <personne name="blabla" prénom="blibli" />
> Evidement, il y a un prix : c'est une syntaxe verbeuse et horrible, enfin à
> mon avis ...
> Car l'objectif est bel et bien un langage que nous utiliserons (moi le
> premier), alors il faut que des développeurs puissent avoir envie de
> programmer avec.
>
> Donc, une syntaxe à la C pour résumer.
>
> Nous fabriquons une application complète, le premier élément sera donc
> <application>
> Les symboles > et < sont à comprendre comme une espèce de BNF, çà n'est pas
> de l'XML.
> Par exemple :
>
> application test1 {
>        lang = fr;
> }
>
> Il faut identifier la langue dans laquelle les spécifications sont faites,
> c'est donc une sorte d'attribut de l'application.
> Je préfère lang = fr plutôt que lang : fr, histoire que cela ressemble à un
> attribut comme en Java. Qu'en pensez-vous ?
>
> test1 est le nom, disons "technique" de l'application, mais il y a un nom
> plus "end user". Comment le spécifier ?
> Je propose 2 options, laquelle préférez-vous et pourquoi ?
>
> option 1 :
> application test1 "C'est mon premier test" {
>        lang = fr;
> }
>
> option 2 :
> @name("C'est mon premier test")
> application test1 {
>        lang = fr;
> }
>
> option 3 :
> application test1 {
>        lang = fr;
>        name = "C'est mon premier test";
> }
>
> Le nom long doit avoir des guillemet, pas le nom technique qui du coup ne
> doit pas avoir d'espace ou de caractères trop "exotiques", comme le nom
> d'une classe en Java.
>
> Evidement, à part une ressemblance bien réelle avec une annotation, çà
> n'est pas une annotation.
> En conséquence, je voix ne doit jamais se faire par rapport à des
> considérations techniques.
> Seule la "beauté", la simplicité de la grammaire compte.
>
> L'option 2 est plus verbeuse, mais permettra d'ajouter facilement d'autres
> éléments qui vont arriver.
> L'option 1 est plus sobre et moins connoté Java.
> L'option 3 est un peu trop JSON à mon gout, nous envisageons un langages,
> pas une sorte de fichier properties ...
>
>
> D'une manière générale, à la Java/C, les éléments dans les {} ne sont pas
> ordonnés.
> Ainsi :
> application nom {
>        a;
>        b;
> }
>
> est équivalent à
> application nom {
>        b;
>        a;
> }
>
>
> En revanche, en dehors des {}, l'ordre est important comme par exemple pour
> l'option 1.
> application nom "nom long".
>
>
> Il y a tout de même une contrainte technique : une grammaire doit pouvoir
> se définir pour fabriquer un lexer/parser avec SableCC ou Tatoo (pas encore
> décidé lequel mais on utilise déjà SableCC à plusieurs reprise dans notre
> compilo)
> Bref, vos commentaires sont les bienvenus !
>
> JBB.