Ecrire du C (ou autre langage) en XML

Programmation
#1

Bonjour à tous

Je me demandais s’il existait une DTD (pour du XML donc) qui permettait de coder des applications en pseudo-code.

Je m’explique.

J’imaginais un truc comme ça en XML :

<code>

 <getinput var="test"/>
 <if test="hello">
   <print>Hello world!</print>
  <elseif test="bye">
   <print>Bye bye!</print>
  <else>
   <print>Nothing</print>
 </if>

</code>

Avec un truc comme ça, on peut très facilement le convertir en C à l’aide de XSLT, mais également dans n’importe quel autre langage de programmation. Ca permet d’avoir un langage universel qui se convertit ensuite dans n’importe quel langage pour le compiler pour n’importe quelle architecture. Alors certes on ne va peut être pas coder un bootloader avec un truc pareil (quoique ?), mais ça n’est pas le but. Ca serait plutôt d’offrir un moyen très simple de porter du code dans tout un tas de langages différents pour des architectures différentes.

Vous pourrez également me dire que c’est un peu pour ça que Java a été conçu, mais là c’est différent car il s’agit de traiter du pseudo-code pour le rendre compilable sur n’importe quelle plateforme. On peut d’ailleurs très bien convertir mon pseudo-code en assembleur directement !

Comme je n’ai pas envie de réinventer la roue, je me demandais si ça existait déjà ?

Merci à vous

#2

Si le portage d’un langage a un autre reposait juste là dessus, ça irait. Tu ne fais juste qu’écrire un arbre syntaxique de ton programme en C. la diffulté est que ces arbres diffèrent (peu mais diffèrent) d’un langage à un autre. Pense au LISP, à Caml, à ADA, etc.

#3

Un exemple de problème qui pourrait se poser ?

#4

Le gros problème du portage ne réside pas dans la syntaxe des langages. Le C est portable, tu compile facilement du C (89 ou 99) sur tout ce qui peut exécuter du code. Le problème c’est par exemple quand tu commence à manipuler des fichiers par exemple (les chemins de fichiers ne sont pas les même sous Windows et sous Unix).

Les langages qui se veulent portables comme python ou Java possèdent dans le bibliothèque standard des mécanisme permettant d’avoir des chemins génériques qui s’exécuteront différemment selon l’environnement (pour Java tu as System Properties et File).

Généralement c’est surtout un problème de volonté/compétence du développeur.

#5

Essaye de transposer en C le programme suivant:

let recursif test fonctionSitest expression nouvelArgument =
       let rec f x = if (test x) then (fonctionSitest x)
                     else (expression x (f (nouvelArgument x)))
       in f;;

avec comme test

let test x = x=0;;
let fonctionSitest _ = 1;;
let expression x y = x*y;;
let nouvelArgument x = x-1;;

let factoriel = recursif test fonctionSitest expression nouvelArgument;;

(factoriel 6) te renvoit bien sûr 720. Tu m’en diras des nouvelles. Note que j’ai réussi à faire la transcription partielle de ce truc en C mais il a fallu revoir complètement la sémantique des objets. Il est heureux que certains langages aient des spécificités fortes, c’est ce qui fait la valeur de langage comme par exemple ici Caml.

#6

Sinon, plus simplement, tu auras le souci des appels par valeurs vs les appels par variables, les variables globales et locales, les gestions d’exceptions et bien sûr les soucis de programmation insupportable type passage d’argument par registre, c’est ce qui me vient à l’esprit. Tu auras également à gérer si tu passes en ADA tous les soucis de déclarations implicites dans certains langages par exemple, les soucis de changements de types, de polymorphismes, etc. Bref, l’horreur.

#7

Je ne serais pas aussi pessimiste que mes illustres confrères, je trouve ton approche très intéressante, et je suis même étonné que cela n’existe pas déjà !
Si tu à envie de développer un truc dans le genre, n’hésite pas, lance-toi !

#8

Je vois…

Toutefois il ne s’agit pas de concevoir quelque chose qui puisse convertir du C en Caml, mais de programmer directement en pseudo-code et ensuite de convertir ce code en code compilable.

Autrement dit, si j’ai la chose suivante :

<code>

<print>
 <factorielle val="6"/>
</print>

</code>

et bien si on veut le convertir en C, on va générer l’algo qui va bien (et qui sera toujours le même pour la balise ), et en Caml on va générer un autre code qui permettra également d’obtenir le résultat souhaité. Mais à aucun moment on ne va tenter de convertir du Caml en C.

Je ne souhaite pas faire en sorte que l’on puisse utiliser toutes les subtilités de chaque langage en XML, mais l’inverse : ce qui est écrit en XML devient compilable en un autre langage.

En fait l’idée est un peu comme ce que l’on fait aujourd’hui par rapport à l’assembleur. Tous les langages compilés sont en fait compilés en assembleur au final. Et on est loin d’obtenir un code assembleur toujours très optimisé. Mais écrire en C ou en Python (OK ce dernier est interprété mais ça ne change pas grand chose) facilite énormément la tâche des développeurs. Pourtant ces langages ne permettent pas d’obtenir toutes les subtilités de l’assembleur (même si le C permet beaucoup de choses). On délaisse quelque peu l’optimisation au profit de plus de flexibilité et de clarté du code, pour gagner en temps et en fiabilité.

Et bien là ça serait la même chose. On ne cherche pas à donner la possibilité d’utiliser toutes les subtilités du C ou du Python, mais à avoir un code facile à maintenir et à transcrire dans un langage ou un autre.

Et bien justement, si j’ai un pseudo-code en XML, je peux le transcrire en Python ou Java directement et donc le rendre portable immédiatement sur n’importe quelle machine.

[quote]Je ne serais pas aussi pessimiste que mes illustres confrères, je trouve ton approche très intéressante, et je suis même étonné que cela n’existe pas déjà !
Si tu à envie de développer un truc dans le genre, n’hésite pas, lance-toi ![/quote]
Je pense effectivement commencer quelque chose pour voir jusqu’où il est possible d’aller et mettre en évidence les plus grosses difficultés. Je vais commencer pour le C et je pense continuer avec du Python. Je ne suis pas du tout sûr de ce que je vais obtenir et quelles vont être les barrières mais je pense que ça peut valoir le coup d’essayer.

#9

[quote=“Cluxter”]]
Je vois…

Toutefois il ne s’agit pas de concevoir quelque chose qui puisse convertir du C en Caml, mais de programmer directement en pseudo-code et ensuite de convertir ce code en code compilable.

Autrement dit, si j’ai la chose suivante :

<code>

<print>
 <factorielle val="6"/>
</print>

</code>

et bien si on veut le convertir en C, on va générer l’algo qui va bien (et qui sera toujours le même pour la balise ), et en Caml on va générer un autre code qui permettra également d’obtenir le résultat souhaité. Mais à aucun moment on ne va tenter de convertir du Caml en C.

[/quote]
J’avoue que je n’ai pas bien compris. Si tu veux faire du passage XML vers langage de programmation, tôt ou tard, il te faudra fabriquer le code, donc te heurter à cette difficulté: tu vas devoir mettre une sémantique sur ton XML et je doute fort que tu puisses trouver une sémantique commune convenant à ces deux langages, sauf à te restreindre à deux sous ensembles qui enlèveront tout intérêt aux dits langages; en gros par exemple tu peux faire du C en Caml mais ça n’a pas de sens.

[quote]
Je ne souhaite pas faire en sorte que l’on puisse utiliser toutes les subtilités de chaque langage en XML, mais l’inverse : ce qui est écrit en XML devient compilable en un autre langage.
[/quote]Certes mais dans ce cas, ça perd énormément d’intérêt. Le mieux est de prendre un sous ensemble du C, un compilateur, tu récupères le parseur et tu modifies juste la génération de code. Ça a été fait pour transposer du Pascal en C par exemple.[quote]
En fait l’idée est un peu comme ce que l’on fait aujourd’hui par rapport à l’assembleur. Tous les langages compilés sont en fait compilés en assembleur au final. Et on est loin d’obtenir un code assembleur toujours très optimisé. Mais écrire en C ou en Python (OK ce dernier est interprété mais ça ne change pas grand chose) facilite énormément la tâche des développeurs. Pourtant ces langages ne permettent pas d’obtenir toutes les subtilités de l’assembleur (même si le C permet beaucoup de choses). On délaisse quelque peu l’optimisation au profit de plus de flexibilité et de clarté du code, pour gagner en temps et en fiabilité.[/quote]
Par ler de subtilité sur l’assembleur est osé, c’est quand même très primaire par définition. Par ailleurs tu es rude avec le code fabriqué par gcc par exemple, jette un oeil dessus, c’est possible de l’améliorer à la marge mais ça n’est pas simple loin de là.

[quote]

Et bien là ça serait la même chose. On ne cherche pas à donner la possibilité d’utiliser toutes les subtilités du C ou du Python, mais à avoir un code facile à maintenir et à transcrire dans un langage ou un autre.

[/quote]Franchement, j’ai du mal à en voir l’intérêt, l’assembleur est lié à une machine, c’est son inconvénient majeur et ça justifie l’existence des compilateurs. Après les langages ont un intérêt propre du fait de leur spécificité: tu choisis le C pour l’efficacité du code, son interface avec le noyau et la possibilité de gérer facilement du matériel, le Caml pour la puissance de ses structures de données, le Cobol pour la compatibilité avec l’existant dans ta boite, etc. Autant un outil permettant de passer d’un langage à un autre se comprend et est intéressant, autant un meta langage te donne l’inconvénient de tous les langages et aucun des avantages. La question est qui s’en servirait et surtout dans quel but?

Mais si tu veux le faire, la marche est assez simple:
Tu fabriques un parseur (avec le XML, c’est rapide) et tu organises l’arbre du programme.
Puis pour chaque langage, tu fabriques un traducteur fabriquant un code générique pour tes primitives. Bref c’est un compilateur avec juste un choix de sortie pour le code final. Je pense d’ailleurs que très rapidement, tu seras tenté de faire un interpréteur, c’est presque plus simple, puis un compilateur complet.
Ce sera très formateur mais je pense que tu seras déçu au final.

#10

C’est précisément le point qui me chagrine et c’est pour ça que ça risquerait selon moi de ne pas être réellement utile au final.

[quote]
Mais si tu veux le faire, la marche est assez simple:
Tu fabriques un parseur (avec le XML, c’est rapide) et tu organises l’arbre du programme.
Puis pour chaque langage, tu fabriques un traducteur fabriquant un code générique pour tes primitives. Bref c’est un compilateur avec juste un choix de sortie pour le code final. Je pense d’ailleurs que très rapidement, tu seras tenté de faire un interpréteur, c’est presque plus simple, puis un compilateur complet.
Ce sera très formateur mais je pense que tu seras déçu au final.[/quote]
Si c’est formateur pour moi, au moins ce ne sera pas inutile :slightly_smiling:
Après effectivement je risque d’être déçu si je me rends compte que ça ne donne rien d’exploitable en pratique. Je pense qu’il faut tester pour voir jusqu’où on peut aller.

#11

Je vois ça dans l’optique de créer des “tubes” entre différents systèmes gérés par différents administrateurs.
Par exemple tu développe qqs macros externes à ton projet qui lui utilise un langage que tu as choisis.
Ces macros tu les développes en ANSI-UTF8-Cluxter (faut bien ça :wink:) tu les valides chez toi, avec ton langage, et ensuite peut importe la plateforme de ton client, il devra les compiler dans son langage, mais du moment que les spécifications sont garanties la macro fonctionnera.

PS : Dépêche toi de créer les specs et les compilateurs pour le C,Java et BASH … Tu as trois jours !