June 2004 - Transformers

Compilers and Compiler Generators
by Clement Vasseur 25 Aug '04

25 Aug '04

Compilers and Compiler Generators an introduction with C++ (C) P.D. Terry, Rhodes University, 1996 http://www.scifac.ru.ac.za/compilers/ This site provides an on-line edition of the text and other material from my book "Compilers and Compiler Generators - an introduction with C++", published in 1997 by International Thomson Computer Press. The original edition is now out of print, and the copyright has reverted to me. http://www.scifac.ru.ac.za/compilers/contg.htm Le chapitre 11 parle de grammaires attribuées. -- Clement Vasseur -o) [ nitro :: EPITA CSI 2005 ] /\\ "Programming is about being lazy." _\_V

2 1

eh/cleanup1 removal
by Clement Vasseur 01 Jul '04

01 Jul '04

I propose the removal of the eh/cleanup1 test. This one depends on a patched version of SGLR, it is huge and takes a lot of time to run, and best of all it randomly fails. See bug #37 on gforge: "This test always fail, but never at the same place." It prevents the auto-build system to install cxx-grammar and test the packages that depends on it. Very annoying. Any objection? -- Clement Vasseur -o) [ nitro :: EPITA CSI 2005 ] /\\ "Programming is about being lazy." _\_V

2 2

Re: [Transformers] Vérification des types pour c-grammar.
by valentin＠lrde.epita.fr 01 Jul '04

01 Jul '04

spip <spip(a)lrde.epita.fr> writes: > Bonjour, > > Je mail ici ce dont je n'ai pas eu le temps de parler à la réunion ce > matin pour manque de temps. Après l'effort commun fournit sur c-grammar, > je me posais la question suivante: > > Ne serait-il pas préférable de commencer par le typechecking > sur la grammaire du C plutot que sur celle du C++ ? > > La grammaire du C fonctionne déjà avec les grammaires attribuées, ce qui > est la voie qui doit être empruntée ! Ensuite la grammaire étant moins > ambigue, ce sera plus simple pour expérimenter avant de s'attaquer au > gros tank pour le C++. > > Mais la vraie question est : implémenter la vérification des types sur > la grammaire du C a t'elle un sens ? est ce necessaire ? est ce juste un > luxe inutile ? > > Perso, je pense que ça ne peut être que bénéfique pour une première > expérimentation du "mariage" parsing/désambiguisation et une nouveauté > en plus pour la 0.2. > > Any suggestion ? ;-) We need it, but it is not so important for 0.2. If it can be done, do it. Else it can be done for the 0.3 some weeks or month after. -- Valentin David valentin(a)lrde.epita.fr

2 1

Re: [Transformers] Vérification des types pour c-grammar.
by yann＠lrde.epita.fr 01 Jul '04

01 Jul '04

spip <spip(a)lrde.epita.fr> writes: > Mais la vraie question est : implémenter la vérification des types sur > la grammaire du C a t'elle un sens ? est ce necessaire ? est ce juste un > luxe inutile ? Hum. Est-ce qu'il ne suffirait pas de faire une propagation des sortes ? Si on sépare les identifiants qui dénotent les types, les types d'ordre sup', et ceux qui dénotent des valeurs, on doit avoir réglé un gros nombre d'ambiguïté, non ? Il me semblait que Robert était allé dans cette voie.

2 2

Vérification des types pour c-grammar.
by spip 30 Jun '04

30 Jun '04

Bonjour, Je mail ici ce dont je n'ai pas eu le temps de parler à la réunion ce matin pour manque de temps. Après l'effort commun fournit sur c-grammar, je me posais la question suivante: Ne serait-il pas préférable de commencer par le typechecking sur la grammaire du C plutot que sur celle du C++ ? La grammaire du C fonctionne déjà avec les grammaires attribuées, ce qui est la voie qui doit être empruntée ! Ensuite la grammaire étant moins ambigue, ce sera plus simple pour expérimenter avant de s'attaquer au gros tank pour le C++. Mais la vraie question est : implémenter la vérification des types sur la grammaire du C a t'elle un sens ? est ce necessaire ? est ce juste un luxe inutile ? Perso, je pense que ça ne peut être que bénéfique pour une première expérimentation du "mariage" parsing/désambiguisation et une nouveauté en plus pour la 0.2. Any suggestion ? ;-)

1 0

Esdf parser.
by valentin＠lrde.epita.fr 28 Jun '04

28 Jun '04

On c-grammar, when using det-gen, it fails because the definition file uses extensions of sdf-attribute. The esdf parser is really needed. Nicolas, when will you be able to write it? -- Valentin David valentin(a)lrde.epita.fr

2 1

GCC test suites.
by valentin＠lrde.epita.fr 24 Jun '04

24 Jun '04

Do we need to have the GCC test suites into the repository ? Cannot we have a script that downloads, untars, and adds into the package tree automatically. It is very long to checkout and we do not need to modify it. -- Valentin David valentin(a)lrde.epita.fr

3 2

Adjacent string literals
by Clement Vasseur 23 Jun '04

23 Jun '04

Olivier found out the following fact: As stated in sections 2.1 and 2.13.4 of the C++ standard, adjacent string literals must be concatenated during the translation phase. const char* s = "bon" "jour." "\n"; is equivalent to: const char* s = "bonjour.\n"; Here is the difference in the AST: StringLiteral(STRING-LITERAL("\"bon\" \"jour.\" \"\\n\"")) vs StringLiteral(STRING-LITERAL("\"bonjour.\\n\"")) Is it parse-cxx job to perform this concatenation, using a desugaring filter? -- Clement Vasseur -o) [ nitro :: EPITA CSI 2005 ] /\\ "Programming is about being lazy." _\_V

2 1

Generalized Parsing and Term Rewriting: Semantics Driven Disambiguation
by Clement Vasseur 21 Jun '04

21 Jun '04

J'ai finalement retrouvé l'article que nous avait donné Mark van den Brand lors du ASF+SDF Users Day en 2003 : Generalized Parsing and Term Rewriting: Semantics Driven Disambiguation M. van den Brand, A. Klusener, L. Moonen and J. Vinju Generalized parsing technology provides the power and flexibility to attack real-world parsing applications. However, many programming languages have syntactical ambiguities that can only be solved using semantical analysis. In this paper we propose to apply the paradigm of term rewriting to filter ambiguities based on semantical information. We start with the definition of a representation of ambiguous derivations. Then we extend term rewriting with means to handle such derivations. Finally, we apply these tools to some real world examples, namely C and COBOL. The resulting architecture is simple and efficient as compared to semantic directed parsing. http://www1.elsevier.com/gej-ng/31/29/23/133/52/30/82.3.008.pdf -- Clement Vasseur -o) [ nitro :: EPITA CSI 2005 ] /\\ "Programming is about being lazy." _\_V

2 1

[Eelco Visser] Dynamic rules paper
by Akim Demaille 15 Jun '04

15 Jun '04

1 0