parser de grammaire

Laurent Deniau

10/08/2006 à 12:38

Sylvain wrote:

Laurent Deniau wrote on 09/08/2006 17:02:

et ça n'avance en rien mon bouzin ... ma question est: connaissez-vous
une lib. C++ pour ce type de process ? pas une interrogation
métaphysique sur l'art de décrire une analyse de texte (d'autre NG
seraient plus pertinents).

Etant donne que tu as l'air d'etre un expert en techniques de parsing,
la litterature sur le sujet ne te sera d'aucune aide et je pense que tu
n'auras aucune difficulte pour ecrire tes propres outils en quelques
jours et mener a bien ton projet. Revient nous voir quand tu auras fini
pour nous faire partager tes avancees.

a+, ld.

Jean-Marc Bourguet

10/08/2006 à 18:00

Sylvain writes:

Jean-Marc Bourguet wrote on 10/08/2006 11:31:
Avant de regarder comment utiliser les programmes, je te

oulah, je ne les utilise pas rassure-toi, j'en code uniquement.

suggère de lire un peu de théorie sinon à forcer d'employer
les mots dans un sens différent de celui qu'ils ont acquis
dans le domaine

"ils ont acquis" ?!? tout seul ?

Je ne suis pas linguiste et je connais mal le processus par
lequel les mots et les expressions acquièrent un sens.

btw, dans quel domaine ? linguistique ? ce n'est pas mon point.
informatique ?

Informatique.

mon but n'était pas "d'employer des mots" mais plutôt de
coder une représentation de fonctions simples.

Tu peux donner le sens que tu veux aux mots et aux
expressions, mais quand tu poses des questions, si ce sens
n'est pas celui généralement admis dans le contexte dans
lequel tu poses tes questions, tu vas au devant de
problèmes. Tu peux naturellement prétendre que c'est les
autres qui ont un problème, mais c'est toi qui n'aura pas de
réponses pertinentes.

tu ne comprendras rien et personne ne te comprendra. Une
référence: http://www.cs.vu.nl/~dick/PTAPG.html

un bouquin épuisé en anglais ?! proposer cela à un mec qui
ne comprend rien est sûrement de l'ironie.

Il faut lire jusqu'au bout... le bouquin est disponible en
PDF et en Postscript.

A+

--
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

Gabriel Dos Reis

10/08/2006 à 22:51

Sylvain writes:

| j'ai peur d'avoir perdu le fil, ou alors il est parti en sucette assez
| loin de ma question initiale

On se demande bien pourquoi et comment.

-- Gaby

Jean-Marc Bourguet

11/08/2006 à 07:46

Sylvain writes:

Jean-Marc Bourguet wrote on 10/08/2006 18:00:
Tu peux donner le sens que tu veux aux mots et aux
expressions, mais quand tu poses des questions, si ce sens
n'est pas celui généralement admis dans le contexte dans
lequel tu poses tes questions, tu vas au devant de
problèmes. Tu peux naturellement prétendre que c'est les
autres qui ont un problème, mais c'est toi qui n'aura pas de
réponses pertinentes.

j'ai donné des sens-à-moi ? j'ai prétendu ? ...

Au strict minimum à "analyse lexicale" quand tu as écrit (ta
seconde intervention dans le fil):

l'analyse syntaxique est OK mais l'analyse lexicale est
absente

et que tu as persisté après que Laurent et Loïc ont suggéré
qu'il y avait une confusion.

Après avoir lu cela, je n'ai même plus cherché à voir
laquelle des deux interprétations que j'avais de ta question
initiale était la bonne.

--
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

Jean-Marc Bourguet

11/08/2006 à 10:54

Sylvain writes:

Jean-Marc Bourguet wrote on 11/08/2006 07:46:
Au strict minimum à "analyse lexicale" quand tu as écrit (ta
seconde intervention dans le fil):

l'analyse syntaxique est OK mais l'analyse lexicale est
absente

oui et ?? tu ne le conçois pas comme cela donc cela ne
peut exister ??

Je ne le conçois en effet pas sans changer le sens
d'"analyse lexicale".

Traditionellement, on conçoit la partie validation d'un
langage en trois phases:

1/ analyse lexicale: transformation d'un flux de caractères
en un flux de symboles (par exemple: identificateur,
opérateur, nombre, ...) souvent accompagné d'annotation (le
texte exact du symbole, sa position dans le flux, sa
valeur, ...) Il y a souvent de la lattitude quant à ce qui
constitue un symbole ou non (par exemple: est-ce qu'on a un
symbole opérateur accompagné d'une annotation indiquant de
quel opérateur il s'agit ou bien un symbole par opérateur;
ou en C++ est-ce que "toto" " titi" est un symbole ou deux).
Cette phase s'occupe aussi de virer les blancs non
significatifs, les commentaires,...

2/ analyse grammaticale: transformation du flux de symboles
en un arbre syntaxique

3/ analyse sémantique: validation des énoncés (est-ce que
les règles de type sont respectées, est-ce que des règles
comme l'absence de définitions multiples d'identificateurs
sont respectées, vérification d'un identificateur a bien une
signification dans le contexte où il est utilisé).

pour les scripts à traiter ici, il est pertinent de
vérifier la stricte syntaxe (validité des opérateurs,
niveaux de parenthèses, etc) avant de traiter la validité
lexicale (identification des lexèmes nommant des variables
ou fonctions) qui tient plus d'une analyse grammaticale
(dont analyse de structures type for, if then, try catch,
...)

C'est de l'analyse sémantique pour moi et tous les auteurs
que j'ai lu.

ma question est: connaissez-vous (par l'expérience, pas par Google) une
librairie C++ implémentant un moteur de scripts (type JavaScript ou
AppleScript).

Oui: TCL, mais c'est du C.

--
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

Sylvain <noSpam@mail.net> writes:

Jean-Marc Bourguet wrote on 11/08/2006 07:46:

Au strict minimum à "analyse lexicale" quand tu as écrit (ta
seconde intervention dans le fil):

l'analyse syntaxique est OK mais l'analyse lexicale est
absente

oui et ?? tu ne le conçois pas comme cela donc cela ne
peut exister ??

Je ne le conçois en effet pas sans changer le sens
d'"analyse lexicale".

Traditionellement, on conçoit la partie validation d'un
langage en trois phases:

1/ analyse lexicale: transformation d'un flux de caractères
en un flux de symboles (par exemple: identificateur,
opérateur, nombre, ...) souvent accompagné d'annotation (le
texte exact du symbole, sa position dans le flux, sa
valeur, ...) Il y a souvent de la lattitude quant à ce qui
constitue un symbole ou non (par exemple: est-ce qu'on a un
symbole opérateur accompagné d'une annotation indiquant de
quel opérateur il s'agit ou bien un symbole par opérateur;
ou en C++ est-ce que "toto" " titi" est un symbole ou deux).
Cette phase s'occupe aussi de virer les blancs non
significatifs, les commentaires,...

2/ analyse grammaticale: transformation du flux de symboles
en un arbre syntaxique

3/ analyse sémantique: validation des énoncés (est-ce que
les règles de type sont respectées, est-ce que des règles
comme l'absence de définitions multiples d'identificateurs
sont respectées, vérification d'un identificateur a bien une
signification dans le contexte où il est utilisé).

pour les scripts à traiter ici, il est pertinent de
vérifier la stricte syntaxe (validité des opérateurs,
niveaux de parenthèses, etc) avant de traiter la validité
lexicale (identification des lexèmes nommant des variables
ou fonctions) qui tient plus d'une analyse grammaticale
(dont analyse de structures type for, if then, try catch,
...)

C'est de l'analyse sémantique pour moi et tous les auteurs
que j'ai lu.

ma question est: connaissez-vous (par l'expérience, pas par Google) une
librairie C++ implémentant un moteur de scripts (type JavaScript ou
AppleScript).

Oui: TCL, mais c'est du C.

--
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

Vous avez filtré cet utilisateur ! Consultez son message

Sylvain writes:

Jean-Marc Bourguet wrote on 11/08/2006 07:46:
Au strict minimum à "analyse lexicale" quand tu as écrit (ta
seconde intervention dans le fil):

l'analyse syntaxique est OK mais l'analyse lexicale est
absente

oui et ?? tu ne le conçois pas comme cela donc cela ne
peut exister ??

Je ne le conçois en effet pas sans changer le sens
d'"analyse lexicale".

Traditionellement, on conçoit la partie validation d'un
langage en trois phases:

1/ analyse lexicale: transformation d'un flux de caractères
en un flux de symboles (par exemple: identificateur,
opérateur, nombre, ...) souvent accompagné d'annotation (le
texte exact du symbole, sa position dans le flux, sa
valeur, ...) Il y a souvent de la lattitude quant à ce qui
constitue un symbole ou non (par exemple: est-ce qu'on a un
symbole opérateur accompagné d'une annotation indiquant de
quel opérateur il s'agit ou bien un symbole par opérateur;
ou en C++ est-ce que "toto" " titi" est un symbole ou deux).
Cette phase s'occupe aussi de virer les blancs non
significatifs, les commentaires,...

2/ analyse grammaticale: transformation du flux de symboles
en un arbre syntaxique

3/ analyse sémantique: validation des énoncés (est-ce que
les règles de type sont respectées, est-ce que des règles
comme l'absence de définitions multiples d'identificateurs
sont respectées, vérification d'un identificateur a bien une
signification dans le contexte où il est utilisé).

pour les scripts à traiter ici, il est pertinent de
vérifier la stricte syntaxe (validité des opérateurs,
niveaux de parenthèses, etc) avant de traiter la validité
lexicale (identification des lexèmes nommant des variables
ou fonctions) qui tient plus d'une analyse grammaticale
(dont analyse de structures type for, if then, try catch,
...)

C'est de l'analyse sémantique pour moi et tous les auteurs
que j'ai lu.

ma question est: connaissez-vous (par l'expérience, pas par Google) une
librairie C++ implémentant un moteur de scripts (type JavaScript ou
AppleScript).

Oui: TCL, mais c'est du C.

--
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

Gabriel Dos Reis

11/08/2006 à 13:40

Laurent Deniau writes:

| Jean-Marc Bourguet wrote:
| > Sylvain writes:
| > Traditionellement, on conçoit la partie validation d'un
| > langage en trois phases:
| > 1/ analyse lexicale: transformation d'un flux de caractères
| > en un flux de symboles (par exemple: identificateur,
| > opérateur, nombre, ...) souvent accompagné d'annotation (le
| > texte exact du symbole, sa position dans le flux, sa
| > valeur, ...) Il y a souvent de la lattitude quant à ce qui
| > constitue un symbole ou non (par exemple: est-ce qu'on a un
| > symbole opérateur accompagné d'une annotation indiquant de
| > quel opérateur il s'agit ou bien un symbole par opérateur;
| > ou en C++ est-ce que "toto" " titi" est un symbole ou deux).
| > Cette phase s'occupe aussi de virer les blancs non
| > significatifs, les commentaires,...
| > 2/ analyse grammaticale: transformation du flux de symboles
| > en un arbre syntaxique
|
| La grammaire inclue generalement les regles/expressions lexicales, je
| prefere donc parler d'analyse syntaxique pour le 2/ (Lexemes ->
| AST). C'est le cas du C/C++ (pour revenir sur le sujet).

Je ne suis pas sûr de comprendre « Lexemes -> AST ».
Qu'est-ce que cela veut dire ?

| > 3/ analyse sémantique: validation des énoncés (est-ce que
| > les règles de type sont respectées, est-ce que des règles
| > comme l'absence de définitions multiples d'identificateurs
| > sont respectées, vérification d'un identificateur a bien une
| > signification dans le contexte où il est utilisé).
|
| L'ambiguite a laquelle je faisait allusion pour C/C++ impose une
| analyse semantique (du contexte) pour valider une analyse
| syntaxique. C'est pour ca que j'ai parler d'analyses incrementales
| imbriquees.

Cela dépend de la technologie de parsing utilisée. Si on utilise GLR,
on peut s'autoriser des ambiguités et renvoyer la balle à d'autres
phases qui utiliseront des informations semantiques pour virer les AST
erronnées.

-- Gaby

Laurent Deniau <laurent.deniau@cern.ch> writes:

| Jean-Marc Bourguet wrote:
| > Sylvain <noSpam@mail.net> writes:
| > Traditionellement, on conçoit la partie validation d'un
| > langage en trois phases:
| > 1/ analyse lexicale: transformation d'un flux de caractères
| > en un flux de symboles (par exemple: identificateur,
| > opérateur, nombre, ...) souvent accompagné d'annotation (le
| > texte exact du symbole, sa position dans le flux, sa
| > valeur, ...) Il y a souvent de la lattitude quant à ce qui
| > constitue un symbole ou non (par exemple: est-ce qu'on a un
| > symbole opérateur accompagné d'une annotation indiquant de
| > quel opérateur il s'agit ou bien un symbole par opérateur;
| > ou en C++ est-ce que "toto" " titi" est un symbole ou deux).
| > Cette phase s'occupe aussi de virer les blancs non
| > significatifs, les commentaires,...
| > 2/ analyse grammaticale: transformation du flux de symboles
| > en un arbre syntaxique
|
| La grammaire inclue generalement les regles/expressions lexicales, je
| prefere donc parler d'analyse syntaxique pour le 2/ (Lexemes ->
| AST). C'est le cas du C/C++ (pour revenir sur le sujet).

Je ne suis pas sûr de comprendre « Lexemes -> AST ».
Qu'est-ce que cela veut dire ?

| > 3/ analyse sémantique: validation des énoncés (est-ce que
| > les règles de type sont respectées, est-ce que des règles
| > comme l'absence de définitions multiples d'identificateurs
| > sont respectées, vérification d'un identificateur a bien une
| > signification dans le contexte où il est utilisé).
|
| L'ambiguite a laquelle je faisait allusion pour C/C++ impose une
| analyse semantique (du contexte) pour valider une analyse
| syntaxique. C'est pour ca que j'ai parler d'analyses incrementales
| imbriquees.

Cela dépend de la technologie de parsing utilisée. Si on utilise GLR,
on peut s'autoriser des ambiguités et renvoyer la balle à d'autres
phases qui utiliseront des informations semantiques pour virer les AST
erronnées.

-- Gaby

Vous avez filtré cet utilisateur ! Consultez son message

Laurent Deniau

11/08/2006 à 15:03

Gabriel Dos Reis wrote:

Laurent Deniau writes:

| Jean-Marc Bourguet wrote:
| > Sylvain writes:
| > Traditionellement, on conçoit la partie validation d'un
| > langage en trois phases:
| > 1/ analyse lexicale: transformation d'un flux de caractères
| > en un flux de symboles (par exemple: identificateur,
| > opérateur, nombre, ...) souvent accompagné d'annotation (le
| > texte exact du symbole, sa position dans le flux, sa
| > valeur, ...) Il y a souvent de la lattitude quant à ce qui
| > constitue un symbole ou non (par exemple: est-ce qu'on a un
| > symbole opérateur accompagné d'une annotation indiquant de
| > quel opérateur il s'agit ou bien un symbole par opérateur;
| > ou en C++ est-ce que "toto" " titi" est un symbole ou deux).
| > Cette phase s'occupe aussi de virer les blancs non
| > significatifs, les commentaires,...
| > 2/ analyse grammaticale: transformation du flux de symboles
| > en un arbre syntaxique
|
| La grammaire inclue generalement les regles/expressions lexicales, je
| prefere donc parler d'analyse syntaxique pour le 2/ (Lexemes ->
| AST). C'est le cas du C/C++ (pour revenir sur le sujet).

Je ne suis pas sûr de comprendre « Lexemes -> AST ».
Qu'est-ce que cela veut dire ?

Je veux parler de la phase d'analyse syntaxique (validation de la
syntaxe), c'est a dire la tranformation d'un "flux" de lexeme (i.e.
entree de yacc/bison) en arbre syntaxique (i.e. sortie de yacc/bison).

Je n'ai jamais essaye, mais a la vue des grammaires de C/C++, on devrait
pouvoir eviter le decoupage en lexeme et traiter directement un flux de
caracteres (i.e. lexeme quand meme ;-) ) au prix d'une probable perte
d'efficacite et d'une augmentation importante d'etats.

| > 3/ analyse sémantique: validation des énoncés (est-ce que
| > les règles de type sont respectées, est-ce que des règles
| > comme l'absence de définitions multiples d'identificateurs
| > sont respectées, vérification d'un identificateur a bien une
| > signification dans le contexte où il est utilisé).
|
| L'ambiguite a laquelle je faisait allusion pour C/C++ impose une
| analyse semantique (du contexte) pour valider une analyse
| syntaxique. C'est pour ca que j'ai parler d'analyses incrementales
| imbriquees.

Cela dépend de la technologie de parsing utilisée. Si on utilise GLR,
on peut s'autoriser des ambiguités et renvoyer la balle à d'autres
phases qui utiliseront des informations semantiques pour virer les AST
erronnées.

Yep mais le resultat n'est plus un arbre mais un graphe acyclique en cas
d'ambiguite. On voit ceux qui s'interesse (entre autre) a Haskell ;-)
J'ai jamais regarde en detail, mais m'est avis que l'evaluation
paresseuse joue un role dans ce type de parser.

a+, ld.

Gabriel Dos Reis wrote:

Laurent Deniau <laurent.deniau@cern.ch> writes:

| Jean-Marc Bourguet wrote:
| > Sylvain <noSpam@mail.net> writes:
| > Traditionellement, on conçoit la partie validation d'un
| > langage en trois phases:
| > 1/ analyse lexicale: transformation d'un flux de caractères
| > en un flux de symboles (par exemple: identificateur,
| > opérateur, nombre, ...) souvent accompagné d'annotation (le
| > texte exact du symbole, sa position dans le flux, sa
| > valeur, ...) Il y a souvent de la lattitude quant à ce qui
| > constitue un symbole ou non (par exemple: est-ce qu'on a un
| > symbole opérateur accompagné d'une annotation indiquant de
| > quel opérateur il s'agit ou bien un symbole par opérateur;
| > ou en C++ est-ce que "toto" " titi" est un symbole ou deux).
| > Cette phase s'occupe aussi de virer les blancs non
| > significatifs, les commentaires,...
| > 2/ analyse grammaticale: transformation du flux de symboles
| > en un arbre syntaxique
|
| La grammaire inclue generalement les regles/expressions lexicales, je
| prefere donc parler d'analyse syntaxique pour le 2/ (Lexemes ->
| AST). C'est le cas du C/C++ (pour revenir sur le sujet).

Je ne suis pas sûr de comprendre « Lexemes -> AST ».
Qu'est-ce que cela veut dire ?

Je veux parler de la phase d'analyse syntaxique (validation de la
syntaxe), c'est a dire la tranformation d'un "flux" de lexeme (i.e.
entree de yacc/bison) en arbre syntaxique (i.e. sortie de yacc/bison).

Je n'ai jamais essaye, mais a la vue des grammaires de C/C++, on devrait
pouvoir eviter le decoupage en lexeme et traiter directement un flux de
caracteres (i.e. lexeme quand meme ;-) ) au prix d'une probable perte
d'efficacite et d'une augmentation importante d'etats.

| > 3/ analyse sémantique: validation des énoncés (est-ce que
| > les règles de type sont respectées, est-ce que des règles
| > comme l'absence de définitions multiples d'identificateurs
| > sont respectées, vérification d'un identificateur a bien une
| > signification dans le contexte où il est utilisé).
|
| L'ambiguite a laquelle je faisait allusion pour C/C++ impose une
| analyse semantique (du contexte) pour valider une analyse
| syntaxique. C'est pour ca que j'ai parler d'analyses incrementales
| imbriquees.

Cela dépend de la technologie de parsing utilisée. Si on utilise GLR,
on peut s'autoriser des ambiguités et renvoyer la balle à d'autres
phases qui utiliseront des informations semantiques pour virer les AST
erronnées.

Yep mais le resultat n'est plus un arbre mais un graphe acyclique en cas
d'ambiguite. On voit ceux qui s'interesse (entre autre) a Haskell ;-)
J'ai jamais regarde en detail, mais m'est avis que l'evaluation
paresseuse joue un role dans ce type de parser.

a+, ld.

Vous avez filtré cet utilisateur ! Consultez son message

Gabriel Dos Reis wrote:

Laurent Deniau writes:

| Jean-Marc Bourguet wrote:
| > Sylvain writes:
| > Traditionellement, on conçoit la partie validation d'un
| > langage en trois phases:
| > 1/ analyse lexicale: transformation d'un flux de caractères
| > en un flux de symboles (par exemple: identificateur,
| > opérateur, nombre, ...) souvent accompagné d'annotation (le
| > texte exact du symbole, sa position dans le flux, sa
| > valeur, ...) Il y a souvent de la lattitude quant à ce qui
| > constitue un symbole ou non (par exemple: est-ce qu'on a un
| > symbole opérateur accompagné d'une annotation indiquant de
| > quel opérateur il s'agit ou bien un symbole par opérateur;
| > ou en C++ est-ce que "toto" " titi" est un symbole ou deux).
| > Cette phase s'occupe aussi de virer les blancs non
| > significatifs, les commentaires,...
| > 2/ analyse grammaticale: transformation du flux de symboles
| > en un arbre syntaxique
|
| La grammaire inclue generalement les regles/expressions lexicales, je
| prefere donc parler d'analyse syntaxique pour le 2/ (Lexemes ->
| AST). C'est le cas du C/C++ (pour revenir sur le sujet).

Je ne suis pas sûr de comprendre « Lexemes -> AST ».
Qu'est-ce que cela veut dire ?

Je veux parler de la phase d'analyse syntaxique (validation de la
syntaxe), c'est a dire la tranformation d'un "flux" de lexeme (i.e.
entree de yacc/bison) en arbre syntaxique (i.e. sortie de yacc/bison).

Je n'ai jamais essaye, mais a la vue des grammaires de C/C++, on devrait
pouvoir eviter le decoupage en lexeme et traiter directement un flux de
caracteres (i.e. lexeme quand meme ;-) ) au prix d'une probable perte
d'efficacite et d'une augmentation importante d'etats.

| > 3/ analyse sémantique: validation des énoncés (est-ce que
| > les règles de type sont respectées, est-ce que des règles
| > comme l'absence de définitions multiples d'identificateurs
| > sont respectées, vérification d'un identificateur a bien une
| > signification dans le contexte où il est utilisé).
|
| L'ambiguite a laquelle je faisait allusion pour C/C++ impose une
| analyse semantique (du contexte) pour valider une analyse
| syntaxique. C'est pour ca que j'ai parler d'analyses incrementales
| imbriquees.

Cela dépend de la technologie de parsing utilisée. Si on utilise GLR,
on peut s'autoriser des ambiguités et renvoyer la balle à d'autres
phases qui utiliseront des informations semantiques pour virer les AST
erronnées.

Yep mais le resultat n'est plus un arbre mais un graphe acyclique en cas
d'ambiguite. On voit ceux qui s'interesse (entre autre) a Haskell ;-)
J'ai jamais regarde en detail, mais m'est avis que l'evaluation
paresseuse joue un role dans ce type de parser.

a+, ld.

Gabriel Dos Reis

11/08/2006 à 15:55

Laurent Deniau writes:

[...]

| Yep mais le resultat n'est plus un arbre mais un graphe acyclique en
| cas d'ambiguite. On voit ceux qui s'interesse (entre autre) a Haskell
| ;-)
| J'ai jamais regarde en detail, mais m'est avis que l'evaluation
| paresseuse joue un role dans ce type de parser.

Il y a aussi le parseur Elkhound (pour C++).

-- Gaby

Laurent Deniau

11/08/2006 à 16:55

Gabriel Dos Reis wrote:

Laurent Deniau writes:

[...]

| Yep mais le resultat n'est plus un arbre mais un graphe acyclique en
| cas d'ambiguite. On voit ceux qui s'interesse (entre autre) a Haskell
| ;-)
| J'ai jamais regarde en detail, mais m'est avis que l'evaluation
| paresseuse joue un role dans ce type de parser.

Il y a aussi le parseur Elkhound (pour C++).

Je ne connaissais, c'est note. Les messages d'erreurs ont l'air bien
mieux que ceux de bison. Sur le site on trouve quand meme:

c: Contains a C parser written in Elkhound. The grammar is almost free
of shift/reduce conflicts. It uses the lexer hack (feedback from the
symbol table into the lexer) to distinguish variables from types.

pabo ;-)

a+, ld.

Jean-Marc Bourguet

11/08/2006 à 18:27

Laurent Deniau writes:

La grammaire inclue generalement les regles/expressions
lexicales, je prefere donc parler d'analyse syntaxique
pour le 2/ (Lexemes -> AST). C'est le cas du C/C++ (pour
revenir sur le sujet).

Les deux sont en effet utilisé plus ou moins
indifféremment.

3/ analyse sémantique: validation des énoncés (est-ce que
les règles de type sont respectées, est-ce que des règles
comme l'absence de définitions multiples d'identificateurs
sont respectées, vérification d'un identificateur a bien une
signification dans le contexte où il est utilisé).

L'ambiguite a laquelle je faisait allusion pour C/C++
impose une analyse semantique (du contexte) pour valider
une analyse syntaxique. C'est pour ca que j'ai parler
d'analyses incrementales imbriquees.

Il y a toujours des complications; elles sont parfois due a
une volonté d'utilisé des outils plus simple mais ayant des
limitations, elles sont parfois intrinsèques au langage.

J'ai oublié aussi d'écrire que cette division est
essentiellement pragmatique. Suivant les cas on peut
déplacer des traitements d'une phase à une autre. Par
exemple si on utilise des grammaires contextuelles, on peut
placer dans l'analyse syntaxique des contraintes
habituellement considérées comme sémantiques. Des facteurs
qui interviennent sont le choix des outils utilisés (lex
permet de faire un peu plus que des expressions rationnelles
par exemple), la simplicité du résultat (traiter les
blancs et les commentaires dans la grammaire, c'est
possible, c'est simplement pas conseillé) et les perfs.

--
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

parser de grammaire

10 réponses

Veuillez sélectionner un problème