C++

Analyse lexicale & syntaxique avec Boost::Spirit

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Analyse lexicale & syntaxique avec Boost::Spirit

Amonchakai

Bonjour,

Je suis en train d'essayer de parser du code source Caml à l'aide de Boost::Spirit. (L'objectif étant à terme de convertir le code Caml en métaprog C++ à l'aide de boost::mpl)
J'ai eu l'occasion de voir cette idée que très récemment, donc je ne suis que sur le début...
Pour le moment, je commence par la phase où il y a pas trop besoin de réfléchir: parser le Caml...

Globalement, le parsage avec boost:spirit marche pas trop mal. J'ai juste 3 sourcis:

(Le code source est dispo là: http://www.mediafire.com/?gdcyuwwx1mm )

* Le premier est le suivant: je comprend pas bien pourquoi, mais j'ai des erreurs bizare sous gcc 4.4.1-1 sous Arch Linux alors que sous Win / VS 9.0 SP 1 pas de souci

Citation :

....
Parser.hpp:379:79: attention : caractère(s) nul(s) ignoré(s)
Parser.hpp:380:1: attention : caractère(s) nul(s) ignoré(s)
Parser.hpp:381:1: attention : caractère(s) nul(s) ignoré(s)
Parser.hpp:382:1: attention : caractère(s) nul(s) ignoré(s)
Parser.hpp:383:1: attention : caractère(s) nul(s) ignoré(s)
Parser.hpp:383:3: attention : caractère(s) nul(s) ignoré(s)
Parser.hpp:384:1: attention : caractère(s) nul(s) ignoré(s)
Parser.hpp:385:1: attention : caractère(s) nul(s) ignoré(s)
Parser.hpp:386:1: attention : caractère(s) nul(s) ignoré(s)
Parser.hpp:387:1: attention : caractère(s) nul(s) ignoré(s)
In file included from main.cpp:2:
Parser.hpp:15: erreur: ‘v’ does not name a type
Parser.hpp:29: erreur: expected unqualified-id before ‘/’ token
In file included from main.cpp:2:
Parser.hpp:37: erreur: ‘t’ does not name a type

Et les lignes désignées par le compilateur me semblent vraiment sans aucun problèmes... (par ex: la 15 c'est juste un commentaire )

* mon deuxième souci est sur le parsage des chaines de caractères pour les noms de fonctions et variable...
Basiquement l'expression régulière est

Code :

([a...z] | '_' )([a...z] | '_' | [0-9] | ''' )*

soit dans boost::spirit

Code :

+( letter | ch_p('_') ) >> *(letter | digit_p | ch_p('_') | ch_p('\''))
letter = letterUpCase | letterLowCase;
letterUpCase = range<>('A','Z');
letterLowCase = range<>('a','z');

Mais ce que je comprend pas c'est qu'il a l'air de me prendre aussi les espaces... du coup, si je rentre un truc du genre:

Code :

test as test2

il me parse toute la chaine "test as test2" comme le nom d'une variable
Dans la doc de Spirit, il y a des info pour ne pas tenir compte des espaces dans des cas particulier (comme pour gérer les nombres du type "12 000" ) Mais j'ai rien trouvé pour résoudre mon problème... Si vous avez une idée...

* Le troisième souci que j'ai est au niveau de certaines expressions du type:

Code :

expr -> constante
| variable
| "(" expr " )"
| "begin" expr "end"
| "if" expr "then" expr ["else" expr]
...
| expr operateur expr
| expr (expr)+
| expr ; expr
| expr "::" expr

Le souci étant sur la deuxième partie: avec Spirit, ce type de cas conduit sur de la récursion infinie. Il est nécessaire d'avoir autre chose que l'expression en première partie. Du coup, je me dit qu'il fraudait faire quelque chose du genre:

Code :

expr -> constante
| variable
| "(" expr " )"
| "begin" expr "end"
| "if" expr "then" expr ["else" expr]
...
| variable operateur expr
| "(" expr " )" operateur expr
| "begin" expr "end" operateur expr
| "if" expr "then" expr ["else" expr] operateur expr
...

Mais comme j'ai pas envie de me taper les !4 * n expressions... j'avais pensé à ça: (en Spirit)

Code :

startExpr = longest_d[
constant
| value_name
| "(" >> expr >> " )"
| "begin" >> expr >> "end"
| "[" >> expr >> *( ";" >> expr) >> "]"
| "if" >> expr >> "then" >> expr >> !("else" >> expr)
| "match" >> expr >> "with" >> pattern_matching
| "let" >> !(str_p("rec" )) >> let_binding >> "in" >> expr
| "function" >> pattern_matching
| "fun" >> multiple_matching
];
startExpr2 = longest_d[
startExpr
| startExpr >> "::" >> expr
| startExpr >> +(expr)
| startExpr >> ";" >> expr
| startExpr >> infix_op >> expr
];
expr = longest_d[
startExpr2
| startExpr2 >> "::" >> expr
| startExpr2 >> +(expr)
| startExpr2 >> ";" >> expr
| startExpr2 >> infix_op >> expr
];

Mais cela n'a pas l'air de bien marcher: quand j'associe une règle a exécuter lors de la reconnaissance des constantes pour vérifier une expression du type "3 + 4 ;;" J'ai l'impression de voir toutes les tentative d'association qu'il a fait. Du coup, il m'appelle plein de fois la règle associé à la reconnaissance du 3 et 4... (un exemple de ce pb est directement visible dans le code source complet posté ci dessus)

(la solution où je tapais tout avait l'air de marcher... mais bon, c'est pas vraiment une solution... Je ferai comment le jours où j'aurai 7 règles récursive comme ceci..)

Bon globalement à part la question des noms de variables je suis capable de vérifier si ce qui est tapé vérifie la grammaire de Caml. Mais je me demandais si vous auriez une idée pour résoudre mes derniers problèmes...

Merci!

Message édité par Amonchakai le 09-09-2009 à 14:10:34

Publicité

Joel F

Real men use unique_ptr

Je te conseillerais d eposter sur la ML Boost.Spirit ou Joel et Harmut sauront te repondre si tu leur file un exemple simple compilable.

2ement, tu fais ça pour qui ? Car j'ai exactement le mm projet dans mes cartons ...

Message édité par Joel F le 09-09-2009 à 16:07:00

Amonchakai

Bonjour,

O.K. merci pour votre réponse, je vais préparer des exemples compilable qui illustrent mes différents problèmes et je les posterai sur la ML de Boost.Spirit. Honnêtement, quand j'ai créé ce topic je pensais précisément à vous, en espérant que vous ayez une solution...

Pour la question "pour qui est ce que je fais ça?", en fait je fais cela pour moi. En réalité, j'ai trouvé cela sur votre site dans la section "offre de stage" (d'où le fait que cela soit dans vos carton)... Je trouvais que cela était vraiment une très bonne idée (et que j'aimerai également avoir cet outil...). Donc je souhaiterai mener a bien ce projet.

Je tiendrai à jour ce topic pour donner les réponse que j'aurai eu a ce sujet (et aussi demander des conseil sur le design pour la génération du code).

Merci!

Message cité 1 fois

Joel F

Real men use unique_ptr

Amonchakai a écrit :

O.K. merci pour votre réponse, je vais préparer des exemples compilable qui illustrent mes différents problèmes et je les posterai sur la ML de Boost.Spirit. Honnêtement, quand j'ai créé ce topic je pensais précisément à vous, en espérant que vous ayez une solution...

C'est la gloire

Amonchakai a écrit :

Pour la question "pour qui est ce que je fais ça?", en fait je fais cela pour moi. En réalité, j'ai trouvé cela sur votre site dans la section "offre de stage" (d'où le fait que cela soit dans vos carton)... Je trouvais que cela était vraiment une très bonne idée (et que j'aimerai également avoir cet outil...). Donc je souhaiterai mener a bien ce projet.

Hahaha je me disais aussi :whistle:

Amonchakai a écrit :

Je tiendrai à jour ce topic pour donner les réponse que j'aurai eu a ce sujet (et aussi demander des conseil sur le design pour la génération du code).

OK, n'hesite pas non plus à passer par mail/MP ca sera peut etre plus efficace

Message cité 1 fois

Evadream -jbd-

Joel F a écrit :

OK, n'hesite pas non plus à passer par mail/MP ca sera peut etre plus efficace

Ah non ! On veut voir le contenu intéressant ici ! [:ddr555]

Amonchakai

@Evadream -jbd- : haha, pas de problèmes

Bon j'ai résolu les problèmes 1. et 3.

Le 1. c'était juste une histoire d'un malencontreux caractère du a un copier/coller de la grammaire Caml depuis la doc de caml...

Pour le 3. on m'a recommandé sur la ML de boost::spirit d'éliminer la récursivité à droite comme cela:

Code :

expr_start =
constant
|| value_name
|| "(" >> expr >> " )"
|| "begin" >> expr >> "end"
|| "[" >> expr >> *( ";" >> expr) >> "]"
|| "if" >> expr >> "then" >> expr >> !("else" >> expr)
|| "match" >> expr >> "with" >> pattern_matching
|| "let" >> !(lexeme["rec"]) >> let_binding >> "in" >> expr
|| "function" >> pattern_matching
|| "fun" >> multiple_matching
;
expr_rest =
"::" >> expr
|| ";" >> expr
|| infix_op >> expr
;
expr = expr_start >> *expr_rest;

Ce qui semble marcher parfaitement.

Pour le pb 2. (les noms de variables), on m'a recommander de quitter la version "classique" de spirit pour passer en V2.1.
Bon, j'avoue me galérer sur le passage à l'autre version: la doc n'est pas vraiment touffue (vu que cette version est encore en béta) Et puis les temps de compilation sont devenu énormément long (mon pauvre petit X40 a bien du mal...)

Bref, je posterai les résultats quand tout sera réglé!

Joel F

Real men use unique_ptr

cherche dans le gmane boost. Joel a posté un lien vers leur doc a jour de memoire.

Apres, moi dans mon optique, je voulais aps forcement lexer tt caml mais un sous ensemble strictement necessaire.

Amonchakai

Oui, c'est bon je l'ai trouvée:
http://www.boost.org/doc/libs/1_40 [...] uick_start

Après en ce qui concerne la grammaire de caml, je me suis restreint à ce qui est décrit ici:
http://www.fil.univ-lille1.fr/~lev [...] TPAst.html

Cela me semble suffisant (du moins dans un premier temps)

Joel F

Real men use unique_ptr

FORUM HardWare.fr

Programmation

C++

Analyse lexicale & syntaxique avec Boost::Spirit

Sujets relatifs
SQL Tableau analyse croisée sur une année glissante	Résolu - Soucis avec boost::bind
boost or not	Mélange port série, C++ et boost::asio
boost:::bind et ref	boost:men_fun
[boost] make_variant_over et mpl::set -> error	Tableau dynamique BOOST
boost::bind	analyse d'un fichier CAD au format STL
Plus de sujets relatifs à : Analyse lexicale & syntaxique avec Boost::Spirit

Page générée en 0.104 secondes