Super chouette article, merci de partager cela. La partie technique me fait penser aux techniques de compilation : tokenisation, reconnaissance de motifs, optimisations (suppression ou remplacement de motifs par d'autres). Quelques remarques qui peuvent t'intéresser ou pas :
- Tu opposes le traitement par tokenisation et l'analyse de zones de textes. En réalité tu n'as pas besoin de choisir, tu peux avoir les deux, vu que d'une série de tokens tu sais revenir à un morceau de texte brut (si ta tokenisation ne perd pas d'information importante), et d'un morceau de texte brut retourner à une séquence de tokens
- En compilation, les tokens ne sont en général pas conservés sous forme de séquence mais sous forme d'arbre (Arbre de syntaxe concrète et/ou abstraite) en fonction de règles de ... grammaire.
Les différentes passes de vérification (pare exemple le typage) se font sur ces arbres.
- Quand tu as des ambiguïtés que tu ne peux résoudre, rien ne t'empêche d'avoir des branches OU dans ton arbre, du type
(Sujet (Article * Nom * Adjectif) | (Sujet (Article * Adjectif * Nom))) * Verbe * Complément
- Certains langages sont mieux équipés que d'autres pour ce genre de traitements. Un langage proposant de la reconnaissance de motifs en natif est d'une valeur inestimable. Je connais et utilise ocaml qui a fait ses preuves dans ce domaine, mais je suis sur qu'il en existe plein d'autres. Il est possible/facile de générer du js de manière efficace depuis du code ocaml avec js_of_ocaml.
# On dirait de la compilation ... mais en plus difficile
Posté par Obi MO (site web personnel) . En réponse à la dépêche Grammalecte, correcteur grammatical. Évalué à 9.
Super chouette article, merci de partager cela. La partie technique me fait penser aux techniques de compilation : tokenisation, reconnaissance de motifs, optimisations (suppression ou remplacement de motifs par d'autres). Quelques remarques qui peuvent t'intéresser ou pas :
- Tu opposes le traitement par tokenisation et l'analyse de zones de textes. En réalité tu n'as pas besoin de choisir, tu peux avoir les deux, vu que d'une série de tokens tu sais revenir à un morceau de texte brut (si ta tokenisation ne perd pas d'information importante), et d'un morceau de texte brut retourner à une séquence de tokens
- En compilation, les tokens ne sont en général pas conservés sous forme de séquence mais sous forme d'arbre (Arbre de syntaxe concrète et/ou abstraite) en fonction de règles de ... grammaire.
Les différentes passes de vérification (pare exemple le typage) se font sur ces arbres.
- Quand tu as des ambiguïtés que tu ne peux résoudre, rien ne t'empêche d'avoir des branches OU dans ton arbre, du type
(Sujet (Article * Nom * Adjectif) | (Sujet (Article * Adjectif * Nom))) * Verbe * Complément
- Certains langages sont mieux équipés que d'autres pour ce genre de traitements. Un langage proposant de la reconnaissance de motifs en natif est d'une valeur inestimable. Je connais et utilise ocaml qui a fait ses preuves dans ce domaine, mais je suis sur qu'il en existe plein d'autres. Il est possible/facile de générer du js de manière efficace depuis du code ocaml avec js_of_ocaml.