Re: Un nouveau langage

Le 02/09/2010 13:32, Sebastien Cesbron a écrit :
> 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

Habituellement, il y a deux parties assez distinctes dans un language,
une partie descriptive et une partie indiquant les actions a effectuer.

Les exemples que tu montres sont descriptifs, ici JSON me semble très bien.
La question suivante est ton language est il typé où non.

struct A {
    int foo default 0;
    string bar;
}
a = A {
    foo = 2;
    bar = 3;
};
est typé.

a = {
    foo = 2
    bar = 3
}
est pas typé


Rémi
précision: lorsqu'on définie un struct en C les élements entre {} sont 
ordonnées.



>
> Le 2 septembre 2010 13:24, Jean-Baptiste BRIAUD -- Novlog 
> <[email protected] <mailto:[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.
>
>