Transformers June 2004

transformers@lrde.epita.fr

7 participants
13 discussions

by Clement Vasseur

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

20 years, 10 months

eh/cleanup1 removal

by Clement Vasseur

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

20 years, 12 months

Re: [Transformers] Vérification des types pour c-grammar.

by valentin＠lrde.epita.fr

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

20 years, 12 months

Re: [Transformers] Vérification des types pour c-grammar.

by yann＠lrde.epita.fr

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.

20 years, 12 months

Vérification des types pour c-grammar.

by spip

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 ? ;-)

21 years

Esdf parser.

by valentin＠lrde.epita.fr

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

21 years

GCC test suites.

by valentin＠lrde.epita.fr

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

21 years

Adjacent string literals

by Clement Vasseur

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

21 years

Generalized Parsing and Term Rewriting: Semantics Driven Disambiguation

by Clement Vasseur

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

21 years

[Eelco Visser] Dynamic rules paper

by Akim Demaille

21 years

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Transformers June 2004