J'écris actuellement un petit parser de code, et je trouve mon code/ma
technique de parsage peu élégante, j'ai donc regardé sur google, j'ai aussi
consulté des codes comme celui de QSA :
http://www.trolltech.com/products/qsa/index.html et j'ai l'impression
qu'ils utilisent une toute technique que la mienne (qui consiste betement à
prendre ligne par ligne puis token par token etc...).
J'ai ensuite recherché de la doc sur la technique mise en place mais sans
grand succès, d'ou ma question ici : connaissez vous de la doc sur une
technique elegante de parsage ou un bouquin ? Car j'aimerai éviter d'avoir
a reecrire mon prog apres l'avoir fini à cause de problème d'inefficacité,
de non-souplesse.
J'écris actuellement un petit parser de code, et je trouve mon code/ma technique de parsage peu élégante, j'ai donc regardé sur google, j'ai aussi consulté des codes comme celui de QSA : http://www.trolltech.com/products/qsa/index.html et j'ai l'impression qu'ils utilisent une toute technique que la mienne (qui consiste betement à prendre ligne par ligne puis token par token etc...).
J'ai ensuite recherché de la doc sur la technique mise en place mais sans grand succès, d'ou ma question ici : connaissez vous de la doc sur une technique elegante de parsage ou un bouquin ? Car j'aimerai éviter d'avoir a reecrire mon prog apres l'avoir fini à cause de problème d'inefficacité, de non-souplesse.
Merci d'avance.
Bonjour,
Vous pouvez sans doute arriver à quelque chose de correct avec Flex++/Bison++. Flex++ génère un scanner, qui renvoie les tokens au parser. Le parser, généré par Bison++, reconnaît une grammaire. Cette solution présente notamment l'avantage d'être plus rapide (souvent), plus fiable, et plus simple à maintenir qu'un parser écrit à la main. Vous pourrez trouver un exemple simple sur http://groups.google.fr/group/comp.compilers/msg/b53e9ed4c263e0c0
ainsi que des explications sur http://www.icce.rug.nl/documents/cplusplus/cppindex.html
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a été utile, mais il ne concerne que le C. Il couvre toutefois correctement les notions liées à l'analyse lexicale et grammaticale, et les problèmes qui peuvent survenir (conflits S/R, R/R, problèmes de reconnaissance). Toujours dans la théorie, lisez les articles de la catégorie http://en.wikipedia.org/wiki/Category:Parsing_algorithms pour comprendre les erreurs de Bison. Les pages de man de Flex et Bison constituent également des sources d'information très riches.
Nicolas.
nico wrote:
Bonjour,
J'écris actuellement un petit parser de code, et je trouve mon code/ma
technique de parsage peu élégante, j'ai donc regardé sur google, j'ai aussi
consulté des codes comme celui de QSA :
http://www.trolltech.com/products/qsa/index.html et j'ai l'impression
qu'ils utilisent une toute technique que la mienne (qui consiste betement à
prendre ligne par ligne puis token par token etc...).
J'ai ensuite recherché de la doc sur la technique mise en place mais sans
grand succès, d'ou ma question ici : connaissez vous de la doc sur une
technique elegante de parsage ou un bouquin ? Car j'aimerai éviter d'avoir
a reecrire mon prog apres l'avoir fini à cause de problème d'inefficacité,
de non-souplesse.
Merci d'avance.
Bonjour,
Vous pouvez sans doute arriver à quelque chose de correct avec
Flex++/Bison++. Flex++ génère un scanner, qui renvoie les tokens au
parser. Le parser, généré par Bison++, reconnaît une grammaire.
Cette solution présente notamment l'avantage d'être plus rapide
(souvent), plus fiable, et plus simple à maintenir qu'un parser écrit à
la main. Vous pourrez trouver un exemple simple sur
http://groups.google.fr/group/comp.compilers/msg/b53e9ed4c263e0c0
ainsi que des explications sur
http://www.icce.rug.nl/documents/cplusplus/cppindex.html
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a
été utile, mais il ne concerne que le C. Il couvre toutefois
correctement les notions liées à l'analyse lexicale et grammaticale, et
les problèmes qui peuvent survenir (conflits S/R, R/R, problèmes de
reconnaissance).
Toujours dans la théorie, lisez les articles de la catégorie
http://en.wikipedia.org/wiki/Category:Parsing_algorithms pour comprendre
les erreurs de Bison.
Les pages de man de Flex et Bison constituent également des sources
d'information très riches.
J'écris actuellement un petit parser de code, et je trouve mon code/ma technique de parsage peu élégante, j'ai donc regardé sur google, j'ai aussi consulté des codes comme celui de QSA : http://www.trolltech.com/products/qsa/index.html et j'ai l'impression qu'ils utilisent une toute technique que la mienne (qui consiste betement à prendre ligne par ligne puis token par token etc...).
J'ai ensuite recherché de la doc sur la technique mise en place mais sans grand succès, d'ou ma question ici : connaissez vous de la doc sur une technique elegante de parsage ou un bouquin ? Car j'aimerai éviter d'avoir a reecrire mon prog apres l'avoir fini à cause de problème d'inefficacité, de non-souplesse.
Merci d'avance.
Bonjour,
Vous pouvez sans doute arriver à quelque chose de correct avec Flex++/Bison++. Flex++ génère un scanner, qui renvoie les tokens au parser. Le parser, généré par Bison++, reconnaît une grammaire. Cette solution présente notamment l'avantage d'être plus rapide (souvent), plus fiable, et plus simple à maintenir qu'un parser écrit à la main. Vous pourrez trouver un exemple simple sur http://groups.google.fr/group/comp.compilers/msg/b53e9ed4c263e0c0
ainsi que des explications sur http://www.icce.rug.nl/documents/cplusplus/cppindex.html
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a été utile, mais il ne concerne que le C. Il couvre toutefois correctement les notions liées à l'analyse lexicale et grammaticale, et les problèmes qui peuvent survenir (conflits S/R, R/R, problèmes de reconnaissance). Toujours dans la théorie, lisez les articles de la catégorie http://en.wikipedia.org/wiki/Category:Parsing_algorithms pour comprendre les erreurs de Bison. Les pages de man de Flex et Bison constituent également des sources d'information très riches.
Nicolas.
nico
Bonjour,
Vous pouvez sans doute arriver à quelque chose de correct avec Flex++/Bison++. Flex++ génère un scanner, qui renvoie les tokens au parser. Le parser, généré par Bison++, reconnaît une grammaire. Cette solution présente notamment l'avantage d'être plus rapide (souvent), plus fiable, et plus simple à maintenir qu'un parser écrit à la main. Vous pourrez trouver un exemple simple sur http://groups.google.fr/group/comp.compilers/msg/b53e9ed4c263e0c0
ainsi que des explications sur http://www.icce.rug.nl/documents/cplusplus/cppindex.html
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a été utile, mais il ne concerne que le C. Il couvre toutefois correctement les notions liées à l'analyse lexicale et grammaticale, et les problèmes qui peuvent survenir (conflits S/R, R/R, problèmes de reconnaissance). Toujours dans la théorie, lisez les articles de la catégorie http://en.wikipedia.org/wiki/Category:Parsing_algorithms pour comprendre les erreurs de Bison. Les pages de man de Flex et Bison constituent également des sources d'information très riches.
Nicolas.
Réponse vraiment très interessant, merci, c'est ce que j'attendais. Je vais maintenant lire tout ca.
-- nico
Bonjour,
Vous pouvez sans doute arriver à quelque chose de correct avec
Flex++/Bison++. Flex++ génère un scanner, qui renvoie les tokens au
parser. Le parser, généré par Bison++, reconnaît une grammaire.
Cette solution présente notamment l'avantage d'être plus rapide
(souvent), plus fiable, et plus simple à maintenir qu'un parser écrit à
la main. Vous pourrez trouver un exemple simple sur
http://groups.google.fr/group/comp.compilers/msg/b53e9ed4c263e0c0
ainsi que des explications sur
http://www.icce.rug.nl/documents/cplusplus/cppindex.html
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a
été utile, mais il ne concerne que le C. Il couvre toutefois
correctement les notions liées à l'analyse lexicale et grammaticale, et
les problèmes qui peuvent survenir (conflits S/R, R/R, problèmes de
reconnaissance).
Toujours dans la théorie, lisez les articles de la catégorie
http://en.wikipedia.org/wiki/Category:Parsing_algorithms pour comprendre
les erreurs de Bison.
Les pages de man de Flex et Bison constituent également des sources
d'information très riches.
Nicolas.
Réponse vraiment très interessant, merci, c'est ce que j'attendais.
Je vais maintenant lire tout ca.
Vous pouvez sans doute arriver à quelque chose de correct avec Flex++/Bison++. Flex++ génère un scanner, qui renvoie les tokens au parser. Le parser, généré par Bison++, reconnaît une grammaire. Cette solution présente notamment l'avantage d'être plus rapide (souvent), plus fiable, et plus simple à maintenir qu'un parser écrit à la main. Vous pourrez trouver un exemple simple sur http://groups.google.fr/group/comp.compilers/msg/b53e9ed4c263e0c0
ainsi que des explications sur http://www.icce.rug.nl/documents/cplusplus/cppindex.html
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a été utile, mais il ne concerne que le C. Il couvre toutefois correctement les notions liées à l'analyse lexicale et grammaticale, et les problèmes qui peuvent survenir (conflits S/R, R/R, problèmes de reconnaissance). Toujours dans la théorie, lisez les articles de la catégorie http://en.wikipedia.org/wiki/Category:Parsing_algorithms pour comprendre les erreurs de Bison. Les pages de man de Flex et Bison constituent également des sources d'information très riches.
Nicolas.
Réponse vraiment très interessant, merci, c'est ce que j'attendais. Je vais maintenant lire tout ca.
-- nico
Loïc Joly
Vous pouvez sans doute arriver à quelque chose de correct avec Flex++/Bison++. Flex++ génère un scanner, qui renvoie les tokens au parser. Le parser, généré par Bison++, reconnaît une grammaire.
Une alternative en C++ qui permet d'éviter la génération de fichiers externes (mais demande un bon compilateur) est boost::spirit que l'on peut trouver sur www.boost.org.
-- Loïc
Vous pouvez sans doute arriver à quelque chose de correct avec
Flex++/Bison++. Flex++ génère un scanner, qui renvoie les tokens au
parser. Le parser, généré par Bison++, reconnaît une grammaire.
Une alternative en C++ qui permet d'éviter la génération de fichiers
externes (mais demande un bon compilateur) est boost::spirit que l'on
peut trouver sur www.boost.org.
Vous pouvez sans doute arriver à quelque chose de correct avec Flex++/Bison++. Flex++ génère un scanner, qui renvoie les tokens au parser. Le parser, généré par Bison++, reconnaît une grammaire.
Une alternative en C++ qui permet d'éviter la génération de fichiers externes (mais demande un bon compilateur) est boost::spirit que l'on peut trouver sur www.boost.org.
-- Loïc
nico
Nicolas wrote:
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a
Je n'arrive pas a le commander ! plus dispo sur fnac & amazon :/
-- nico
Nicolas wrote:
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a
Je n'arrive pas a le commander ! plus dispo sur fnac & amazon :/
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a
Je n'arrive pas a le commander ! plus dispo sur fnac & amazon :/
-- nico
Nicolas
nico wrote:
Nicolas wrote:
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a
Je n'arrive pas a le commander ! plus dispo sur fnac & amazon :/
Ils l'ont chez Eyrolles à Paris : http://www.eyrolles.com/Informatique/Livre/9781565920002/livre-lex-and-yacc.php 29,90 ¤ ou au Monde En Tiques, dans le même quartier http://lmet.fr/fiche.cgi?_ISBN=1-56592-000-7 (32,30 ¤)
En dehors de Paris je ne sais pas.
Ce livre couvre dans une grande partie l'usage de Lex & Yacc (GNU Flex et Bison, à quelques détails près expliqués cela fonctionne pareil), c'est à dire la création d'un scanner et d'un parser et l'interfacage des deux. Pour ce qui est de l'interfacage de Flex++ et Bison++, j'ai eu à le refaire récemment et c'est moins simple. L'exemple sur comp.compilers est d'une grande aide.
Une autre partie, tout aussi importante, est la théorie derrière Lex et Yacc. Les grammaires générées peuvent présenter des ambiguités, et les règles appliquées par défaut doivent être vérifiées en cas de conflit. Des cours universitaires sur la compilation peuvent vous être utiles pour comprendre ces notions. Les PDFs sur cette page http://www.emse.fr/~corbel/COMPIL/ reprennent les notions que j'ai pu apprendre en cours à ce sujet. Le cours à http:/www.liafa.jussieu.fr/%7Emz/enseignement/archive/topics/Compilation/99-00/Transparents-2x2-Compilation.pdf reprend les mêmes sujets, et va plus loin (génération de code, cela n'a pas l'air d'être ce que vous recherchez).
Bien sûr, cela dépend de la complexité de la grammaire utilisée. Une grammaire de reconnaissance d'une formule mathématique avec opérateurs et fonctions est assez simple. Une grammaire de reconnaissance du C++ est bien plus complexe. Intéressez-vous notamment à la sortie de bison (le fichier .output) et aux conflits reportés. Vérifiez que la règle par défaut de Bison en cas de conflit Shift/Reduce est correcte pour chaque conflit, et ne laissez pas de conflit Reduce/Reduce. Bison empile (shift) par défaut. Ces conflits apparaissent notamment si vous construisez les tables First et Follow pour vos symboles.
Je suis en plein dedans en ce moment, vous pouvez me contacter par mail si vous avez besoin d'explications qui dépassent le cadre de ce NG.
Nicolas.
nico wrote:
Nicolas wrote:
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a
Je n'arrive pas a le commander ! plus dispo sur fnac & amazon :/
Ils l'ont chez Eyrolles à Paris :
http://www.eyrolles.com/Informatique/Livre/9781565920002/livre-lex-and-yacc.php
29,90 ¤
ou au Monde En Tiques, dans le même quartier
http://lmet.fr/fiche.cgi?_ISBN=1-56592-000-7 (32,30 ¤)
En dehors de Paris je ne sais pas.
Ce livre couvre dans une grande partie l'usage de Lex & Yacc (GNU Flex
et Bison, à quelques détails près expliqués cela fonctionne pareil),
c'est à dire la création d'un scanner et d'un parser et l'interfacage
des deux. Pour ce qui est de l'interfacage de Flex++ et Bison++, j'ai eu
à le refaire récemment et c'est moins simple. L'exemple sur
comp.compilers est d'une grande aide.
Une autre partie, tout aussi importante, est la théorie derrière Lex et
Yacc. Les grammaires générées peuvent présenter des ambiguités, et les
règles appliquées par défaut doivent être vérifiées en cas de conflit.
Des cours universitaires sur la compilation peuvent vous être utiles
pour comprendre ces notions.
Les PDFs sur cette page http://www.emse.fr/~corbel/COMPIL/ reprennent
les notions que j'ai pu apprendre en cours à ce sujet.
Le cours à
http:/www.liafa.jussieu.fr/%7Emz/enseignement/archive/topics/Compilation/99-00/Transparents-2x2-Compilation.pdf
reprend les mêmes sujets, et va plus loin (génération de code, cela n'a
pas l'air d'être ce que vous recherchez).
Bien sûr, cela dépend de la complexité de la grammaire utilisée. Une
grammaire de reconnaissance d'une formule mathématique avec opérateurs
et fonctions est assez simple. Une grammaire de reconnaissance du C++
est bien plus complexe.
Intéressez-vous notamment à la sortie de bison (le fichier .output) et
aux conflits reportés. Vérifiez que la règle par défaut de Bison en cas
de conflit Shift/Reduce est correcte pour chaque conflit, et ne laissez
pas de conflit Reduce/Reduce. Bison empile (shift) par défaut.
Ces conflits apparaissent notamment si vous construisez les tables First
et Follow pour vos symboles.
Je suis en plein dedans en ce moment, vous pouvez me contacter par mail
si vous avez besoin d'explications qui dépassent le cadre de ce NG.
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a
Je n'arrive pas a le commander ! plus dispo sur fnac & amazon :/
Ils l'ont chez Eyrolles à Paris : http://www.eyrolles.com/Informatique/Livre/9781565920002/livre-lex-and-yacc.php 29,90 ¤ ou au Monde En Tiques, dans le même quartier http://lmet.fr/fiche.cgi?_ISBN=1-56592-000-7 (32,30 ¤)
En dehors de Paris je ne sais pas.
Ce livre couvre dans une grande partie l'usage de Lex & Yacc (GNU Flex et Bison, à quelques détails près expliqués cela fonctionne pareil), c'est à dire la création d'un scanner et d'un parser et l'interfacage des deux. Pour ce qui est de l'interfacage de Flex++ et Bison++, j'ai eu à le refaire récemment et c'est moins simple. L'exemple sur comp.compilers est d'une grande aide.
Une autre partie, tout aussi importante, est la théorie derrière Lex et Yacc. Les grammaires générées peuvent présenter des ambiguités, et les règles appliquées par défaut doivent être vérifiées en cas de conflit. Des cours universitaires sur la compilation peuvent vous être utiles pour comprendre ces notions. Les PDFs sur cette page http://www.emse.fr/~corbel/COMPIL/ reprennent les notions que j'ai pu apprendre en cours à ce sujet. Le cours à http:/www.liafa.jussieu.fr/%7Emz/enseignement/archive/topics/Compilation/99-00/Transparents-2x2-Compilation.pdf reprend les mêmes sujets, et va plus loin (génération de code, cela n'a pas l'air d'être ce que vous recherchez).
Bien sûr, cela dépend de la complexité de la grammaire utilisée. Une grammaire de reconnaissance d'une formule mathématique avec opérateurs et fonctions est assez simple. Une grammaire de reconnaissance du C++ est bien plus complexe. Intéressez-vous notamment à la sortie de bison (le fichier .output) et aux conflits reportés. Vérifiez que la règle par défaut de Bison en cas de conflit Shift/Reduce est correcte pour chaque conflit, et ne laissez pas de conflit Reduce/Reduce. Bison empile (shift) par défaut. Ces conflits apparaissent notamment si vous construisez les tables First et Follow pour vos symboles.
Je suis en plein dedans en ce moment, vous pouvez me contacter par mail si vous avez besoin d'explications qui dépassent le cadre de ce NG.
Nicolas.
nico
Nicolas wrote:
Je suis en plein dedans en ce moment, vous pouvez me contacter par mail si vous avez besoin d'explications qui dépassent le cadre de ce NG.
Ok, merci de votre aide, c'est un sujet vraiment tres interessant, pour le moment je lis les pages man (de bison, flex et yacc)
-- nico
Nicolas wrote:
Je suis en plein dedans en ce moment, vous pouvez me contacter par mail
si vous avez besoin d'explications qui dépassent le cadre de ce NG.
Ok, merci de votre aide, c'est un sujet vraiment tres interessant, pour le
moment je lis les pages man (de bison, flex et yacc)
Le livre lex&yacc (isbn 1-56592-000-7), de Levine, Mason et Brown m'a
Je n'arrive pas a le commander ! plus dispo sur fnac & amazon :/
La version GNU flex et bison viennent avec des manuels tres complets et un mode compatible lex et yacc.
a+, ld.
Laurent Deniau
PurL wrote:
externes (mais demande un bon compilateur) est boost::spirit que l'on
Pouvez-vous me donner des exemple de mauvais compilateurs ?
Il veut probablement dire un compilateur efficace ou alternativement une machine rapide. Parce que spirit est bien pour ecrire des *petits* parseurs. Quand on a une centaines de regles, les temps de compilations deviennent prohibitifs, c'est a dire qques heures (meme s'ils proposent des moyens pour les reduires). Si tu veux faire un package pret a l'installation, il est pas sur que ce soit une solution agreable.
a+, ld.
PurL wrote:
externes (mais demande un bon compilateur) est boost::spirit que l'on
Pouvez-vous me donner des exemple de mauvais compilateurs ?
Il veut probablement dire un compilateur efficace ou alternativement une
machine rapide. Parce que spirit est bien pour ecrire des *petits*
parseurs. Quand on a une centaines de regles, les temps de compilations
deviennent prohibitifs, c'est a dire qques heures (meme s'ils proposent
des moyens pour les reduires). Si tu veux faire un package pret a
l'installation, il est pas sur que ce soit une solution agreable.
externes (mais demande un bon compilateur) est boost::spirit que l'on
Pouvez-vous me donner des exemple de mauvais compilateurs ?
Il veut probablement dire un compilateur efficace ou alternativement une machine rapide. Parce que spirit est bien pour ecrire des *petits* parseurs. Quand on a une centaines de regles, les temps de compilations deviennent prohibitifs, c'est a dire qques heures (meme s'ils proposent des moyens pour les reduires). Si tu veux faire un package pret a l'installation, il est pas sur que ce soit une solution agreable.
a+, ld.
kanze
nico wrote:
J'écris actuellement un petit parser de code, et je trouve mon code/ma technique de parsage peu élégante, j'ai donc regardé sur google, j'ai aussi consulté des codes comme celui de QSA : http://www.trolltech.com/products/qsa/index.html et j'ai l'impression qu'ils utilisent une toute technique que la mienne (qui consiste betement à prendre ligne par ligne puis token par token etc...).
J'ai ensuite recherché de la doc sur la technique mise en place mais sans grand succès, d'ou ma question ici : connaissez vous de la doc sur une technique elegante de parsage ou un bouquin ? Car j'aimerai éviter d'avoir a reecrire mon prog apres l'avoir fini à cause de problème d'inefficacité, de non-souplesse.
Dans le temps, la référence absolue était "Compilers: Principles, Techniques, and Tools", de Aho, Sethi et Ullman (ISBN 0201100886). Aujourd'hui, c'est sans doute un peu daté : n'y cherche pas des renseignements sur la compilation des programmes OO, par exemple, ni sur la génération du code pour des architectures modernes. Mais les explications sont extrèmement claires, et pour une compréhension de base ou pour faire des petits langages interprétés, c'est probablement le meilleur livre disponible encore aujourd'hui.
Je crois qu'il existe aussi une traduction en français, mais je n'ai aucune idée ce qu'elle vaut. (Bien trop de traductions techniques sont franchement lamentables.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
nico wrote:
J'écris actuellement un petit parser de code, et je trouve mon
code/ma technique de parsage peu élégante, j'ai donc regardé
sur google, j'ai aussi consulté des codes comme celui de QSA :
http://www.trolltech.com/products/qsa/index.html et j'ai
l'impression qu'ils utilisent une toute technique que la
mienne (qui consiste betement à prendre ligne par ligne puis
token par token etc...).
J'ai ensuite recherché de la doc sur la technique mise en
place mais sans grand succès, d'ou ma question ici :
connaissez vous de la doc sur une technique elegante de
parsage ou un bouquin ? Car j'aimerai éviter d'avoir a
reecrire mon prog apres l'avoir fini à cause de problème
d'inefficacité, de non-souplesse.
Dans le temps, la référence absolue était "Compilers:
Principles, Techniques, and Tools", de Aho, Sethi et Ullman
(ISBN 0201100886). Aujourd'hui, c'est sans doute un peu daté :
n'y cherche pas des renseignements sur la compilation des
programmes OO, par exemple, ni sur la génération du code pour
des architectures modernes. Mais les explications sont
extrèmement claires, et pour une compréhension de base ou pour
faire des petits langages interprétés, c'est probablement le
meilleur livre disponible encore aujourd'hui.
Je crois qu'il existe aussi une traduction en français, mais je
n'ai aucune idée ce qu'elle vaut. (Bien trop de traductions
techniques sont franchement lamentables.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
J'écris actuellement un petit parser de code, et je trouve mon code/ma technique de parsage peu élégante, j'ai donc regardé sur google, j'ai aussi consulté des codes comme celui de QSA : http://www.trolltech.com/products/qsa/index.html et j'ai l'impression qu'ils utilisent une toute technique que la mienne (qui consiste betement à prendre ligne par ligne puis token par token etc...).
J'ai ensuite recherché de la doc sur la technique mise en place mais sans grand succès, d'ou ma question ici : connaissez vous de la doc sur une technique elegante de parsage ou un bouquin ? Car j'aimerai éviter d'avoir a reecrire mon prog apres l'avoir fini à cause de problème d'inefficacité, de non-souplesse.
Dans le temps, la référence absolue était "Compilers: Principles, Techniques, and Tools", de Aho, Sethi et Ullman (ISBN 0201100886). Aujourd'hui, c'est sans doute un peu daté : n'y cherche pas des renseignements sur la compilation des programmes OO, par exemple, ni sur la génération du code pour des architectures modernes. Mais les explications sont extrèmement claires, et pour une compréhension de base ou pour faire des petits langages interprétés, c'est probablement le meilleur livre disponible encore aujourd'hui.
Je crois qu'il existe aussi une traduction en français, mais je n'ai aucune idée ce qu'elle vaut. (Bien trop de traductions techniques sont franchement lamentables.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
