Bilan de la reunion precedente et proposition de roadmap
Alexandre Bique
Je vais faire au plus bref.
On peut consacrer autant de temps que l'on veut sur un langage, il sera
imparfait et le temps le vieillira encore plus vite qu'il nous vieillit.
Il est toujours possible d'étendre ce langage, mais il aura sa naissance,
son apogée puis sa mort.
Donc il faut accepter quelques points :
- un langage n'est pas extensible a l'infini (si on veut qu'il reste
simple et pratique).
- un langage est imparfait et vieillit vite.
- un langage n'est rien de plus qu'un moyen d'expression.
Conclusion le langage nous limite.
Nous nous focaliserons sur un AST, qui lui est extensible, et même si ça
devient trash, l'utilisateur n'y voit rien. Nous pouvons changer l'ast et
réutiliser ce qui a été exprime a travers un langage.
Le principe en détails :
- plusieurs langages différents permettent d'exprimer l'AST. Ce qui
fait que l'on peut changer le langage.
- nous conservons le principe des modules du D, avec les import.
- quand tu import un module, tu récupères l'AST du modules. Un module
écrit en D peut importer un module ecrit en XYZ.
- changer de langage n'implique pas de perdre ce qui a déjà été fait. Au
contraire.
- un maximum de choses doivent-être standardisées, par exemple ce qu'est
une déclaration de fonction, de structure, etc...
- un langage peut enrichir l'ast avec ces propres noeuds ce qui rend
l'architecture réellement extensible.
- imaginons un Objective D qui gère le message passing (comme en
Objective C).
Le D lui ne le gère pas. On est dans une situation pénible, ou l'on pourra
import un module Objective D, mais on ne pourra pas ou difficilement
manipuler ses nouvelles déclarations. Cela signifie que le D est un vieux
langage et il ne permet pas d'exprimer le message passing. (Pour dire
qu'encore une fois c'est le langage qui limite, pas l'AST).
Cette approche subit le même cycle : naissance, apogée, mort. Mais ce cycle
sera plus long, car il permettra de voir plusieurs cycles de langages, sans
perdre ce qui a déjà été fait.
Une idée en vrac, il est possible de traduire un langage X vers un langage
Y si Y peut exprimer tout ce que X peut exprimer. Je veux dire que si un
projet veut changer de langage il pourrait utiliser un outil qui le ferait
pour lui, sans casser l'API et l'ABI.
Je pense que l'on est d'accord sur ce qui est dit plus haut. Si non nous
pouvons en discuter sur la ml.
Ce que l'on doit faire :
- discuter de ce que l'on standardise dans l'AST, justifier chaque
éléments
avec un petit document et valider l'integration.
- avoir deux langages pour montrer que ça marche.
- définir par quel(s) moyens le front-end determine le langage d'entrée.
On ferait bien de continuer notre front-end D et de le faire marcher. Même
si
c'est un langage incomplet (ne permet pas d'exprimer la constitude etc...),
c'est intéressant de le supporter, ça nous apporterait tout ce qui est fait
en D (les libs surtout), des utilisateurs et de l'expérience.
Résumé :
- on va finir le langage D sans le modifier. (par contre ne comptez pas
sur
moi pour char a[];)
- on va commencer a discuter de ce que l'on standardise dans l'AST, et
comment. Voir les problèmes.
Bisous.
--
Alexandre Bique
{Yaka,Gistr} 2009
Arkanosis
ça me plaît :)
--
Arkanosis
Matthieu Garrigues
C'est cool mais y a un gros points flou pour moi :
A quel niveau d'abstraction du langage on place notre AST?
--
!!! NOUVEAU PORTABLE : 06.50.94.06.23 !!!!!! NOUVEAU FIXE : 09.51.42.69.42 !!!
Garrigues Matthieu
EPITA 2009
Yann Grandmaitre
> - on va finir le langage D sans le modifier. (par contre ne comptez pas
> sur
> moi pour char a[];)
grammaire du D =)
--
Grandmaitre Yann
Ing2 EPITA 2009 -GISTR-
Yaka 2009
Arkanosis
> Le 29/06/08, Alexandre Bique<bique.a...@gmail.com> a écrit :
>> - on va finir le langage D sans le modifier. (par contre ne comptez pas
>> sur
>> moi pour char a[];)
> Tu n'auras pas le choix tu devra autoriser char a[] si c'est dans la
> grammaire du D =)
GCC n'accepte pas export alors que c'est dans la grammaire du C++ :p
--
Arkanosis
Alexandre Bique
<matthieu....@gmail.com> wrote:
> C'est cool mais y a un gros points flou pour moi :
>
> A quel niveau d'abstraction du langage on place notre AST?
Je comprends mal ta question. Je vais quand meme essayer de repondre.
Ce qui compte quand tu import un module, c'est ce qu'il declare.
Ce qu'il fait dans une fonction t'importe peu.
Par exemple on a un langage W, qui a des structures de controles
que tu n'imagines meme pas. W definit un template qui fait des trucs
de dingue.
Toi du code toto.d, et tu import le fameux module ecrit en W. Tu
utilises le template et tu sais l'utiliser car un template est une
chose standard : un nom et des paramettres. Par contre dans le
template il peut y avoir des choses non standard. Mais c'est pas
un probleme. Les noeuds viennent avec leur semantique et le
compilateur lui saura instancier le template etc...
Je dirais qu'il faut que les declarations soient standard.
L'implementation elle est libre.
Attention, cette reponse est prematuree, et c'est notre travail
de definir tout ca.
Alexandre Bique
<yanngra...@gmail.com> wrote:
> Le 29/06/08, Alexandre Bique<bique.a...@gmail.com> a écrit :
>> - on va finir le langage D sans le modifier. (par contre ne comptez
>> pas
>> sur
>> moi pour char a[];)
> Tu n'auras pas le choix tu devra autoriser char a[] si c'est dans la
> grammaire du D =)
>
Si tu y tiens tu pourras faire une branche, hacker le parser
et ajouter le support pour char a[]; // ^^
Matthieu Garrigues
Par exemple en C, si on import un fichier c++ qui utilise les features
du C++ qu'il n'y a pas en C, ca donne quoi?
On importe quoi?
car le fichier C aura pas de moyen d'acceder a types et fonction templatés
Alexandre Bique
<matthieu....@gmail.com> wrote:
> Merci pour la question
Pour la reponse tu veux dire ? :-)
> Par exemple en C, si on import un fichier c++ qui utilise les features
> du C++ qu'il n'y a pas en C, ca donne quoi?
> On importe quoi?
> car le fichier C aura pas de moyen d'acceder a types et fonction
> templatés
Le C/C++ utilise le preprocesseur, donc quand tu compiles,
il remplace #include par le contenu du fichier, et ne parse que du
C ou C++.
Ce qui implique que tu ne peux pas #include du C++ avec du C.
Pour nous, import x, retournera l'ast du module x. Donc on ne
s'interresse pas au langage.