Re: Un nouveau langage

On 2 sept. 2010, at 15:34, Rémi Forax wrote:

> 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.
> 

Oui, nous sommes quasi exclusivement sur du descriptif.
Il y aura bien sur une petite partie plus expressive sur des actions a effectuer ou des règles à respecter.
Plutôt que réinventer la poudre, cela se fera très probablement en javascript.
Par exemple si nous devions envisager une règle énoncant que i doit être inférieur à 3, nous écririons :
i > 3
Je ne sais pas trop quel est ce langage, mais nous l'inclurons via une expression javascript valide, soit :
i > 3
Au point virgule près.
Nous n'aurons jamais de "code" javascript mais plutôt quelques "petit bout de code" javascript saupoudrés dans la partie descriptive. Pas plus que l'équivalent de quelques lignes d'une fonction javascript.
Ce que je veux dire, c'est que nous n'utiliserons pas les mots clés javascript function, ...

> 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é
> 
> 

Plutôt pas typé, il n'y a pas de concept de variable, donc pas de type.
Il y a cependant un concept de "nature de la donnée" (je ne peux pas encore en dire trop) et en ce sens il y a des types.
Disons que l'exemple que tu cite ne s'applique pas, je dirais donc pas typé.

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

Oui, c'est vrai. Seul l'élément Application n'est pas ordonné.
Je me suis donc trompé en affirmant que globalement, l'ordre n'important pas dans les {}.
C'est seulement vrai pour application (} mais pas pour tous les autres concepts.

> 
>> 
>> 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.
>> 
>