Discussion :

[black.out]

Salut,

Voila un petit moment que je bosse sur un langage de script perso.
Je possede pour le moment la machine virtuelle et l'asm correspondant.
Je travail actuellement sur le binding afin de le rendre utilisable avec mes programmes C++.

Je commence a me renseigner sur les methodes de parser/lexer.
Ne sachant que faire j'avais décider de faire cette partie a la fin mais la je ne peux plus y couper.

Donc voici mon souci, comment realiser mon scanner ?

Lex/Yacc and Co :
Je connais tres bien mais je ne suis pas fan. C'est lourd peu portable et pas tres objet meme les version ++ de bison et flex.

Spirit :
Je n'arrive pas a m'y faire, il reste un mystere pour moi :/

Methode perso :
Ca me semble etre la methode la plus adapté, d'autant plus que j'aime comprendre les choses en les reproduisant plutot qu'en les utilisant

Quel est votre avis ? Et dans ce cas auriez vous une doc pour m'aider a demarrer (sauf Lex/Yacc, la ca va )

Merci a tous

EDIT :
Au fait l'idée est venu car le besoin se faisait ressentir pour mon développement de jeux et pour ma GUI perso.

[Jean-Marc.Bourguet]

Si tu veux partir sur quelque chose écrit à la main, ceci peut t'aider:
http://www.oberon.ethz.ch/WirthPubl/CBEAll.pdf

[Bayard]

Avec python

http://www.python.org

c'est un langage de script qui s'interface parfaitement avec le C/C++

[black.out]

Merci pour le lien.

Je vais regarder ca mais ca a l'air de repondre a certaine de mes questions.

Pour python ca ne me branche pas trop, je connais Python ainsi que ruby et TCL mais je cherche plus a comprendre le mecanisme qu'a reinventer la roue

Je laisse en non resolu pour le moment en attendant de parcourir le document et voir si certain aurait d'autre doc.

[JolyLoic]

Juste pour dire qu'il exise un autre truc genre lex/yacc assez connu, que je n'ai jamais utilisé personellement, qui se nomme Antlr (http://www.antlr.org/).

[epsilon68]

il y a une grosse difference entre lex et yacc et antlr !
antlr est LL(n) et yacc est LALR(1)
ecrire une grammaire en LALR est intuitif, l'ecrire en LL est une vrai peine.

dommage que lex et yacc n'ont pas plus evolué, plus objet etc..

ps: tu vois le parsing a la fin pour ton language de script ??? etrange

[Jean-Marc.Bourguet]

il y a une grosse difference entre lex et yacc et antlr !
antlr est LL(n) et yacc est LALR(1)
ecrire une grammaire en LALR est intuitif, l'ecrire en LL est une vrai peine.

LL(1) oui. Du LL(n) beaucoup moins, surtout que pccts (et je crois antlr) permettent du backtracking et des choix semantiques (utiliser le type d'un identificateur pour choisir une production ou une autre). Au fait, spirit etait du LL(1) avec du backtracking quand j'ai regarde.

LL a des avantages quand on regarde les actions semantiques: elles connaissent beaucoup plus du contexte.

[black.out]

J'ai en effet entendu parler de antlr mais le manque de doc m'a legerement repoussé
De plus ca me semble etre un lex/yacc - Like dans le sens qu'il semble etre assez lourd.

Pour le l'ordre des etapes, j'ai décider de faire le parser a la fin car le langage passe par une machine virtuelle. Celle ci interprete un assembleur et redirige sur les fonctions C++ linker au besoin.

Le plus important etait cette étape.
Désormais je peut ecrire mon programme en ASM meme si c'est assez contraignant. Donc je reflechis a un langage plus haut niveau qui me generera mon ASM correspondant.

Ca peut paraitre louche en effet de mais ca me permet de mettre au point plusieurs langages utilisant la meme machine virtuelle (Qui a dit que je me suis inspiré de .NET lol).

En tout cas si vous croiser des articles interressant sur le sujet je suis preneur.

[epsilon68]

LL(1) oui. Du LL(n) beaucoup moins

si je t'assure, il n'y a de toute facon pas beaucoup de grammaire qui sont LL(1).

les grammaires LL sont plus facile a comprendre, et ce sont celles qu'on ecrit generalement a la main. Elles sont malgré tout beaucoup moins intuitive que du LR.

Je n'ai jamais rencontré trop de probleme d'action semantique, sauf si tu veux executer en meme temps que tu parses. Sinon il faut prendre l'habitude de passer par un arbre abstrait, qui te donneras le contexte qui va bien.

a+

[Jean-Marc.Bourguet]

si je t'assure, il n'y a de toute facon pas beaucoup de grammaire qui sont LL(1).

Je ne conteste rien sur LL(1). pccts et antlr sont LL(k) et ca change pas mal, surtout qu'il y a du backtracking integre (donc le k est en fait pratiquement infini) et qu'il y a la possibilite de faire des choix bases sur la semantique (donc on sort de cette classification).

les grammaires LL sont plus facile a comprendre, et ce sont celles qu'on ecrit generalement a la main.

Es-tu sur de parler des grammaires et pas des parseurs? Il y a beaucoup de choses qui font que les grammaires LL(1) sont peut intuitives.

Elles sont malgré tout beaucoup moins intuitive que du LR.

Je suis d'accord que la forme intuitive de certaines constructions est LR et pas LL. Generalement, on peut relativement facilement en trouver une forme LL(1). Encore plus facilement LL(k). Ca ne m'a jamais gener: de toute facon si on veut un traitement d'erreur potable, il faut travailler sur la grammaire. (Et la nature predictive de LL par rapport a LR fait qu'il est generalement plus facile d'avoir un traitement d'erreur potable).

J'ai pas travaille avec antlr; j'ai travaille avec pccts et yacc/bison. Et meme si je connais mieux yacc/bison, pccts ne m'a jamais pose de probleme de capacite de description.

Je n'ai jamais rencontré trop de probleme d'action semantique, sauf si tu veux executer en meme temps que tu parses. Sinon il faut prendre l'habitude de passer par un arbre abstrait, qui te donneras le contexte qui va bien.

Vu la taille des AST que j'avais a traiter, en conserver en memoire quand il y avait moyen de faire autrement n'etait pas une solution.

[epsilon68]

oui bien sûr, ce sont les parseurs LL sont facile a lire, pas les grammaires...
on est d'accord.

[ash.ice.loky]

Je vois black.out que tu avances sur ton projet.

As tu choisis ton type de langage ?
Si tu souhaites toujours faire l'ébauche que tu m'avais envoyé, un parseur à la main seras suffisant.