Re: Un nouveau langage

Quelques remarques rapides :

1) J'ai rien compris :-)

2) Si tu veux faire un truc qui ressemble à du java, alors il est préférable 
que une chose du java ressemble à une même chose dans le nouveau langage, et 
donc qu'une marque d'annotation java soit une sorte d'annotation dans le 
nouveau langage.

3) Il existait jadis un "nouveau langage" qui m'avait beaucoup intéressé, et 
qui ressemble à ton principe de démarrer par une déclaration d'application 
(c'était block, je crois), qui était le SDL, ou LDS en français. (voir 
http://en.wikipedia.org/wiki/Specification_and_Description_Language ou 
http://rangiroa.essi.fr/cours/reseau2/01-SDL.pdf en français). Ça ressemblait 
bien à ton idée que je crois deviner de reprendre les niveaux fonctionnels 
d'une appli. Par contre, pour la simplicité, c'était pas gagné. (mais est-ce 
qu'une appli c'est simple ? )

4) Que penses-tu du travail autour de Roo ? (http://www.springsource.org/roo 
et http://www.springsource.org/roo/why) Ce me semble être un projet pour 
construire le squelette ou maquette d'applications ?


Bon ça suffit les questions pour cette fois, bien que j'en ai encore 
Integer.MAX_VALUE en réserve.


Le jeudi 2 septembre 2010, Jean-Baptiste BRIAUD -- Novlog 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.
>