Juste pour preciser: L ne depend ni de flex ni de yacc.
Pour l'analyse lexicale (equivalent de flex), j'ai ecris une librairie qui analyse un ensemble d'expressions rationnelles, en construit un automate deterministe, et le compile en assembleur. Il n'a pas besoin de dependences exterieures comme la libflex.
La difference avec flex, c'est que flex construit une table pour l'analyse lexicale, qu'il "interprete". Tandis que mes automates sont compiles.
L'interet de ma technique est essentiellement la rapidite, le fait qu'on peut generer des scanners sans dependance exterieure, et le fait que je vais pouvoir directement utiliser ca pour creer ma librairie de regexp. Le desavantage c'est la place prise en memoire (par exemple, on ne peut pas utiliser des tables compressees).
Je n'ai pas fait de tests comparatifs de rapidite avec flex, mais j'en avais fait avec la libpcre (pour une seule expression rationnelle "matchee" en meme temps), et le resultat etait 10x plus rapide que la PCRE. Par contre, on ne gere pas tout ce qui n'est pas vraiment des expressions rationnelles (les trucs comme "<(\w+)>.*<1円>" par exemple), parce que ca ne peut pas etre compile en automate deterministe. Et puis, les extensions necessaires pour recuperer les resultats d'un match ne sont pas encore ecrites.
De meme, je n'utilise pas bison : j'ai ecrit un parser en descente recursive. Ca me permet justement de pouvoir etendre ma syntaxe en rajoutant des parsers au run-time. Pour faciliter l'ecriture de nouveaux parseurs, je prevois l'ecriture d'un "parse language", qui permet d'ecrire la regle de grammaire directement, et qui sera compilee en une fonction de parsing.
Ah, et au final, mon programme genere du code x86 directement en memoire
(ce qui permet un processus de developpement interactif), mais je suis en train de rajouter la possibilite de sortir du C.
[^] # Re: Expliquer...
Posté par Matthieu Lemerre . En réponse au journal Le langage L. Évalué à 3.
Pour l'analyse lexicale (equivalent de flex), j'ai ecris une librairie qui analyse un ensemble d'expressions rationnelles, en construit un automate deterministe, et le compile en assembleur. Il n'a pas besoin de dependences exterieures comme la libflex.
La difference avec flex, c'est que flex construit une table pour l'analyse lexicale, qu'il "interprete". Tandis que mes automates sont compiles.
L'interet de ma technique est essentiellement la rapidite, le fait qu'on peut generer des scanners sans dependance exterieure, et le fait que je vais pouvoir directement utiliser ca pour creer ma librairie de regexp. Le desavantage c'est la place prise en memoire (par exemple, on ne peut pas utiliser des tables compressees).
Je n'ai pas fait de tests comparatifs de rapidite avec flex, mais j'en avais fait avec la libpcre (pour une seule expression rationnelle "matchee" en meme temps), et le resultat etait 10x plus rapide que la PCRE. Par contre, on ne gere pas tout ce qui n'est pas vraiment des expressions rationnelles (les trucs comme "<(\w+)>.*<1円>" par exemple), parce que ca ne peut pas etre compile en automate deterministe. Et puis, les extensions necessaires pour recuperer les resultats d'un match ne sont pas encore ecrites.
De meme, je n'utilise pas bison : j'ai ecrit un parser en descente recursive. Ca me permet justement de pouvoir etendre ma syntaxe en rajoutant des parsers au run-time. Pour faciliter l'ecriture de nouveaux parseurs, je prevois l'ecriture d'un "parse language", qui permet d'ecrire la regle de grammaire directement, et qui sera compilee en une fonction de parsing.
Ah, et au final, mon programme genere du code x86 directement en memoire
(ce qui permet un processus de developpement interactif), mais je suis en train de rajouter la possibilite de sortir du C.