tu as regardé les outils déjà existant qui parsent directement Java -> Ocaml ? Ça existe sûrement, pas mal de gens font de l'analyse statique de Java en OCaml, après leur AST est peut-être pas exactement comme le tien, mais ça me semblerait la méthode la moins fatiguante pour toi
J'ai regardé et c'est imbitable. Fjavac par exemple http://www.cis.upenn.edu/~stevez/stse-work/javac/index.html
En plus, il y a de gros problèmes de compatibilité Java 1.5
Cela dit, j'en ai trouvé un nouveau, mais très vieux ( http://www.cs.cmu.edu/~ecc/joust.tar.gz ) et je vais regarder ça, ou au moins m'en inspirer.
J'ai tourné le problème dans tous les sens, et le fait que je dois construire ma grammaire avec cette méthode me permet de comprendre ce que je fais
Sinon, bah tu n'as pas le bon point de vue : pour toi on donne le "field en cours de construction" aux sous-fonctions qui vont explorer les fils de ton noeud XML pour rajouter les infos. Ça suppose des effets de bords et des trucs pas nets. Il vaut mieux faire l'inverse : ta fonction qui parse les fields _appelle_ les sous-fonctions (c'est elle qui dirige le flot de contrôle, pas les fils), récupère tous les résultats d'un coup et s'en sert pour construire l'enregistrement, en une seule fois.
Donc en gros, j'aurai un truc du genre
Elem ( "field" , infos, fils) ->
{ name_f=cle(infos,"name") ; type_field=match_type fils ; ...}
?
ie., je colle mes fonction d'exploration de l'arbre dans chaque élément que je veux remplir ? Là ce serait match_type fils qui irait chercher les infos en bas ?
C'est ça que tu veux dire ?
Entre nous je pense pas que l'approche XML soit la plus simple pour ton truc. Dans 90% tu as des arbres qui ont "un seul enfant de tel type", en XML tu as une liste d'enfants tous types mélangés, tu dois filtrer sur l'attribut et gérer le cas où il n'y en a aucun/plusieurs, c'est pas très pratique. Tu tiens vraiment à ton frontend XML ?
Les autres approches sont pas simples non plus, javac est imbitable, et joost est trop vieux...
Au moins le xml, je peux le manipuler, et de toutes façon, il ressemble à une grammaire java, donc il a une cohérence...
M'enfin je vais qd même reregarder, mais, entre deux lignes, j'ai reregardé fjavac, et j'y comprend rien, je sais pas où commencer, c'est trop gros, je trouve pas la syntaxe abstraite, etc....
En tout cas, merci beaucoup pour ta réponse :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Problème de point de vue
Posté par Ontologia (site web personnel) . En réponse au message [OCaml] Quel stratégie pour transformer un arbre en grammaire ?. Évalué à 2.
J'ai regardé et c'est imbitable. Fjavac par exemple http://www.cis.upenn.edu/~stevez/stse-work/javac/index.html
En plus, il y a de gros problèmes de compatibilité Java 1.5
Cela dit, j'en ai trouvé un nouveau, mais très vieux ( http://www.cs.cmu.edu/~ecc/joust.tar.gz ) et je vais regarder ça, ou au moins m'en inspirer.
J'ai tourné le problème dans tous les sens, et le fait que je dois construire ma grammaire avec cette méthode me permet de comprendre ce que je fais
Sinon, bah tu n'as pas le bon point de vue : pour toi on donne le "field en cours de construction" aux sous-fonctions qui vont explorer les fils de ton noeud XML pour rajouter les infos. Ça suppose des effets de bords et des trucs pas nets. Il vaut mieux faire l'inverse : ta fonction qui parse les fields _appelle_ les sous-fonctions (c'est elle qui dirige le flot de contrôle, pas les fils), récupère tous les résultats d'un coup et s'en sert pour construire l'enregistrement, en une seule fois.
Donc en gros, j'aurai un truc du genre
Elem ( "field" , infos, fils) ->
{ name_f=cle(infos,"name") ; type_field=match_type fils ; ...}
?
ie., je colle mes fonction d'exploration de l'arbre dans chaque élément que je veux remplir ? Là ce serait match_type fils qui irait chercher les infos en bas ?
C'est ça que tu veux dire ?
Entre nous je pense pas que l'approche XML soit la plus simple pour ton truc. Dans 90% tu as des arbres qui ont "un seul enfant de tel type", en XML tu as une liste d'enfants tous types mélangés, tu dois filtrer sur l'attribut et gérer le cas où il n'y en a aucun/plusieurs, c'est pas très pratique. Tu tiens vraiment à ton frontend XML ?
Les autres approches sont pas simples non plus, javac est imbitable, et joost est trop vieux...
Au moins le xml, je peux le manipuler, et de toutes façon, il ressemble à une grammaire java, donc il a une cohérence...
M'enfin je vais qd même reregarder, mais, entre deux lignes, j'ai reregardé fjavac, et j'y comprend rien, je sais pas où commencer, c'est trop gros, je trouve pas la syntaxe abstraite, etc....
En tout cas, merci beaucoup pour ta réponse :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker