Avez - vous quelques indiquations pour réaliser cela de façon attrayantes ?
Puisque tu poses la question, je suppose que tu ne connais pas les outils permettant de generer les analyseurs. On apprend generalement leur existence et leurs principes dans les formations en informatique.
La premiere question est donc: est-ce que ca vaut la peine d'apprendre a les utiliser? Leur domaine de predilection est les langages de complexite moyenne concus pour pouvoir etre parse par le code genere. Pour les langages fort simple, c'est plus simple de le faire a la main, les langages trop complexes leur posent des problemes, de meme que certaines constructions de langages n'ayant pas ete penses avec leurs limitations. Si la spec du langage bouge beaucoup, c'est un avantage pour les generateurs. Un autre avantage est qu'ils te forcent a considerer les cas limites, ce qui evite des problemes quand le langage evolue. S'il faut des messages d'erreurs evolues sur la syntaxe ou meme une bonne recuperation apres une erreur, c'est un de leur problemes (enfin, j'ai vu des papiers avec des techniques semblant donner de bons resultats, j'ai pas vu d'implementation repandues de ces techniques).
On separe generalement la partie d'analyse lexicale (ou on regroupe les caracteres en symboles, par exemple "Point", "2", "0.1", on en profite pour ignorer les espaces non significatifs et les commentaires) de la partie gramaticale (ou on regroupe les symboles en structure hierarchique de plus haut niveau: expression, statement,...). Il y a des generateurs pour les deux, et d'autres qui essayent de faire les deux.
L'analyse lexicale se fait facilement sans generateur parce qu'il est relativement facile de faire plus performant qu'eux et tout aussi maintenable (et c'est pas ca qui bouge beaucoup). On peut aussi se debrouiller avec des bibliotheques gerant les expressions regulieres (c'est d'ailleurs ce qui est aussi utilise par les generateurs).
La sortie de l'analyse lexicale est generalement une paire compose d'une valeur enumeree indiquant la classe du symbole (identificateur, nombre, parenthese_ouvrante,...) et de son lexeme ou sa valeur ("Point", 0.1).
Pour l'analyse gramaticale, les generateurs construisent generalement des automates a pile ou la fonction d'etat depend de l'etat au sommet de la pile et du symbole non encore accepte. Je passe les details.
A la main, la technique la plus facile est la "descente recursive" ou on ecrit des fonctions parsant les differentes unites gramaticales. Par exemple la fonction parsant les sommes peut ressembler a ceci:
ou symbole_suivant est l'analyseur lexical. Un moyen simple de faire de la gestion d'erreur est de passer aux fonctions la liste des symboles valides apres eux. On a alors:
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avez - vous quelques indiquations pour réaliser cela de façon
attrayantes ?
Puisque tu poses la question, je suppose que tu ne connais pas les
outils permettant de generer les analyseurs. On apprend generalement
leur existence et leurs principes dans les formations en informatique.
La premiere question est donc: est-ce que ca vaut la peine d'apprendre
a les utiliser? Leur domaine de predilection est les langages de
complexite moyenne concus pour pouvoir etre parse par le code genere.
Pour les langages fort simple, c'est plus simple de le faire a la
main, les langages trop complexes leur posent des problemes, de meme
que certaines constructions de langages n'ayant pas ete penses avec
leurs limitations. Si la spec du langage bouge beaucoup, c'est un
avantage pour les generateurs. Un autre avantage est qu'ils te
forcent a considerer les cas limites, ce qui evite des problemes quand
le langage evolue. S'il faut des messages d'erreurs evolues sur la
syntaxe ou meme une bonne recuperation apres une erreur, c'est un de
leur problemes (enfin, j'ai vu des papiers avec des techniques
semblant donner de bons resultats, j'ai pas vu d'implementation
repandues de ces techniques).
On separe generalement la partie d'analyse lexicale (ou on regroupe
les caracteres en symboles, par exemple "Point", "2", "0.1", on en
profite pour ignorer les espaces non significatifs et les
commentaires) de la partie gramaticale (ou on regroupe les symboles en
structure hierarchique de plus haut niveau: expression,
statement,...). Il y a des generateurs pour les deux, et d'autres qui
essayent de faire les deux.
L'analyse lexicale se fait facilement sans generateur parce qu'il est
relativement facile de faire plus performant qu'eux et tout aussi
maintenable (et c'est pas ca qui bouge beaucoup). On peut aussi se
debrouiller avec des bibliotheques gerant les expressions regulieres
(c'est d'ailleurs ce qui est aussi utilise par les generateurs).
La sortie de l'analyse lexicale est generalement une paire compose
d'une valeur enumeree indiquant la classe du symbole (identificateur,
nombre, parenthese_ouvrante,...) et de son lexeme ou sa valeur
("Point", 0.1).
Pour l'analyse gramaticale, les generateurs construisent generalement
des automates a pile ou la fonction d'etat depend de l'etat au sommet
de la pile et du symbole non encore accepte. Je passe les details.
A la main, la technique la plus facile est la "descente recursive" ou
on ecrit des fonctions parsant les differentes unites gramaticales.
Par exemple la fonction parsant les sommes peut ressembler a ceci:
ou symbole_suivant est l'analyseur lexical. Un moyen simple de faire
de la gestion d'erreur est de passer aux fonctions la liste des
symboles valides apres eux. On a alors:
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Avez - vous quelques indiquations pour réaliser cela de façon attrayantes ?
Puisque tu poses la question, je suppose que tu ne connais pas les outils permettant de generer les analyseurs. On apprend generalement leur existence et leurs principes dans les formations en informatique.
La premiere question est donc: est-ce que ca vaut la peine d'apprendre a les utiliser? Leur domaine de predilection est les langages de complexite moyenne concus pour pouvoir etre parse par le code genere. Pour les langages fort simple, c'est plus simple de le faire a la main, les langages trop complexes leur posent des problemes, de meme que certaines constructions de langages n'ayant pas ete penses avec leurs limitations. Si la spec du langage bouge beaucoup, c'est un avantage pour les generateurs. Un autre avantage est qu'ils te forcent a considerer les cas limites, ce qui evite des problemes quand le langage evolue. S'il faut des messages d'erreurs evolues sur la syntaxe ou meme une bonne recuperation apres une erreur, c'est un de leur problemes (enfin, j'ai vu des papiers avec des techniques semblant donner de bons resultats, j'ai pas vu d'implementation repandues de ces techniques).
On separe generalement la partie d'analyse lexicale (ou on regroupe les caracteres en symboles, par exemple "Point", "2", "0.1", on en profite pour ignorer les espaces non significatifs et les commentaires) de la partie gramaticale (ou on regroupe les symboles en structure hierarchique de plus haut niveau: expression, statement,...). Il y a des generateurs pour les deux, et d'autres qui essayent de faire les deux.
L'analyse lexicale se fait facilement sans generateur parce qu'il est relativement facile de faire plus performant qu'eux et tout aussi maintenable (et c'est pas ca qui bouge beaucoup). On peut aussi se debrouiller avec des bibliotheques gerant les expressions regulieres (c'est d'ailleurs ce qui est aussi utilise par les generateurs).
La sortie de l'analyse lexicale est generalement une paire compose d'une valeur enumeree indiquant la classe du symbole (identificateur, nombre, parenthese_ouvrante,...) et de son lexeme ou sa valeur ("Point", 0.1).
Pour l'analyse gramaticale, les generateurs construisent generalement des automates a pile ou la fonction d'etat depend de l'etat au sommet de la pile et du symbole non encore accepte. Je passe les details.
A la main, la technique la plus facile est la "descente recursive" ou on ecrit des fonctions parsant les differentes unites gramaticales. Par exemple la fonction parsant les sommes peut ressembler a ceci:
ou symbole_suivant est l'analyseur lexical. Un moyen simple de faire de la gestion d'erreur est de passer aux fonctions la liste des symboles valides apres eux. On a alors:
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
plindenbaum
hackervalley wrote in message news:<4108c862$0$3440$...
Regarde les logiciels Flex et Bison. Ca genere du C
Ou du C++, il me semble. Mais c'est un peu un lance-missile pour tuer une mouche...
-- ;-)
kanze
Fabien LE LEZ wrote in message news:...
On 29 Jul 2004 10:45:10 -0700, (Pierre):
Regarde les logiciels Flex et Bison. Ca genere du C
Ou du C++, il me semble.
Quelque chose qui se laisse compiler par un compilateur C++ et qui se sert des iostream, en tout cas. Et encore, il faut faire gaffe des versions -- la derniere fois que je me suis servi de Flex, il generait <istream.h>, utilisait les fonctions des anciens flux, et ne se laissait pas compiler avec la bibliotheque standard de g++ 3.x. Il n'y avait rien qu'un petit coup de sed ne pouvait pas regler, mais ca c'etait le cas deja avec le lex standard, il y a 15 ans.
Mais c'est un peu un lance-missile pour tuer une mouche...
Ca depend de ce qui est permis, et ce qui ne l'est pas. Il a donne un exemple simple. Mais les ';' a la fin des lignes suggerent fort qu'il s'agit d'une syntaxe libre. Dans ce cas-la, lance-missile ou non, c'est peut-etre la solution la plus simple a mettre en oeuvre.
-- James Kanze
Fabien LE LEZ <gramster@gramster.com> wrote in message news:<14eig09d5j1iem3oc4sn9vgsudh8j7njls@4ax.com>...
On 29 Jul 2004 10:45:10 -0700, plindenbaum@yahoo.fr (Pierre):
Regarde les logiciels Flex et Bison. Ca genere du C
Ou du C++, il me semble.
Quelque chose qui se laisse compiler par un compilateur
C++ et qui se sert des iostream, en tout cas. Et encore,
il faut faire gaffe des versions -- la derniere fois que
je me suis servi de Flex, il generait <istream.h>,
utilisait les fonctions des anciens flux, et ne se
laissait pas compiler avec la bibliotheque standard de
g++ 3.x. Il n'y avait rien qu'un petit coup de sed ne
pouvait pas regler, mais ca c'etait le cas deja avec
le lex standard, il y a 15 ans.
Mais c'est un peu un lance-missile pour tuer une mouche...
Ca depend de ce qui est permis, et ce qui ne l'est pas.
Il a donne un exemple simple. Mais les ';' a la fin des
lignes suggerent fort qu'il s'agit d'une syntaxe libre.
Dans ce cas-la, lance-missile ou non, c'est peut-etre
la solution la plus simple a mettre en oeuvre.
Regarde les logiciels Flex et Bison. Ca genere du C
Ou du C++, il me semble.
Quelque chose qui se laisse compiler par un compilateur C++ et qui se sert des iostream, en tout cas. Et encore, il faut faire gaffe des versions -- la derniere fois que je me suis servi de Flex, il generait <istream.h>, utilisait les fonctions des anciens flux, et ne se laissait pas compiler avec la bibliotheque standard de g++ 3.x. Il n'y avait rien qu'un petit coup de sed ne pouvait pas regler, mais ca c'etait le cas deja avec le lex standard, il y a 15 ans.
Mais c'est un peu un lance-missile pour tuer une mouche...
Ca depend de ce qui est permis, et ce qui ne l'est pas. Il a donne un exemple simple. Mais les ';' a la fin des lignes suggerent fort qu'il s'agit d'une syntaxe libre. Dans ce cas-la, lance-missile ou non, c'est peut-etre la solution la plus simple a mettre en oeuvre.
