Transformers

transformers@lrde.epita.fr

340 discussions

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, 1 month

Codeboost 0.3.0 NEWS

by PoLRoP

* Compiles with StrategoXT 0.9.5. * Works with autoconf 2.50+, automake 1.7+. * New autoxt based build system: Stratego programs are now compiled to C code, which is then compiled and linked normally. The (architecture independent) C files are included in the tarball distribution, so it is now possible to build CodeBoost without the Stratego compiler, as long as none of the Stratego source files are changed. Furthermore, all Stratego source files have been renamed, and now use the .str extension (instead of .r). * Source tree moved to Subversion: https://svn.cs.uu.nl:12443/repos/codeboost/ * More C++ language features supported: namespace, using (syntactic support only), enum, extern "C", hexadecimal literals, multi-line preprocessor directives. * Semantic analysis is much improved. * Added memoisation makes CodeBoost run 2-3 times faster. * AST changes: + New type representation: Old style used Type(q,n,d), where q was a list of qualifiers (signedness, constness, etc.), n was the type name, and d was the 'declarator-part' of the type (e.g., 'pointer-to' or 'reference-to'). The new style is defined inductively as follows: type := Type(cv-mod-type) cv-mod-type := cv-type | mod-type | Array(expr, cv-mod-type) cv-type := Const(mod-type) | Volatile(mod-type) | Const(Volatile(mod-type)) mod-type := base-type | Ptr(cv-mod-type) | Ref(cv-mod-type) base-type := BaseType(name) | FunType(list(type|Ellipsis), type) For example: int (an integer) => Type(BaseType(IdName("int"))) int* (ptr to int) => Type(Ptr(BaseType(IdName("int")))) const int* (ptr to const int) => Type(Ptr(Const(BaseType(IdName("int"))))) int (*)(const char*, int[5]) (ptr to function taking a pointer to a const char and an array of integers and returning int) => Type(Ptr(FunType([Type(Ptr(Const(BaseType(IdName("char"))))), Type(Array(Int(5), BaseType(IdName("int"))))], Type(BaseType(IdName("int")))))) + No more ManyDecl: Declarations of multiple variables in one statement is split into several consecutive declarations: int a, b, c; -> int a; int b; int c; This means that the ManyDecl constructor is gone, and VarDecl is the only constructor used for declaring variables. For-statements needs special attention: for(int a,b; ...; ...) -> {int a; for(int b; ...; ...)} This means that the meaning of the program changes on non-compliant compilers where 'for' does not define its own scope. + [A utility (src/util/typeconv) is included in the Subversion repository to convert between old-style Type/ManyDecl, and the new style] * Literals are now const. -- Nicolas Desprès nicolas.despres(a)lrde.epita.fr

21 years, 1 month

Une conf. pour Tfers : GPCE

by Akim Demaille

On en parle mercredi.

21 years, 1 month

addPosInfo

by Akim Demaille

Ça ne nous concerne pas ?

21 years, 1 month

Re: Codeboost and Transformers

by Nicolas Despres

Otto Skrove Bagge wrote: > Nicolas Despres <despre_n(a)lrde.epita.fr> writes: > > >>Hello, >> >>We met each other at the fifth Stratego Users Days. I'm part of the >>Transformers team. We try to find a way to bridge the gap between >>Codeboost and Transformers. I mean, we think about writing a stratego >>filter to convert Transformers AST to Codeboost AST. Thus, we could glue >>Transformers front-end with Codeboost back-end. >> >>Transformers release 0.1 is available on the web at >>http://www.lrde.epita.fr/cgi-bin/twiki/view/Projects/TransformersReleases >> >>Have you planed a next release for CodeBoost soon ? > > > Yes, there is a new release, but it has not been annouced yet (since there > really aren't any external users to announce it to, I haven't bothered). > You can get it at > http://download.codeboost.org/codeboost/codeboost-0.3.0.tar.gz > > The subversion repository is also publicly available (svn checkout > https://svn.cs.uu.nl:12443/repos/codeboost/trunk) > > I had a look at Transformers a while ago, and I think it would be a great > idea to have a bridge between Transformers and CodeBoost (especially if > some of you guys are willing to write it...). I'm currently redesigning > the abstract syntax, so it may be a waste of time to write a converter for > the 3.0 AST. However, I noticed that your abstract syntax seems to follow > the standard grammar quite closely; for example, it preserves the extra > productions used for operator precedence. A good starting point might be > to (design and) convert to an intermediate form which doesn't have these > 'unnecessary' constructors. I believe it would then be easy to convert to > CodeBoost's format (whatever it might end up looking like), and perhaps > also interface with other C++ transformation tools. > > The 3.0 abstract syntax is poorly documented. There is a bit of > documentation in my thesis (available from the CodeBoost web page), and > some recent changes are explained in the NEWS file. I'm trying to do a > better job with the new and improved version. Note that while we in > earlier versions of CodeBoost considered it important to preserve as much > syntactic information as possible (e.g., whether the branches of an 'if' > are compound statements or not, or whether some variables are declared in a > single declaration (int a,b;) or in a sequence of declarations (int a; int > b;)), we no longer feel this is important. This means that the CodeBoost > abstract syntax is more like a high-level intermediate than an abstract > representation of C++. > > By the way, I did some experiments with Transformers on the Sophus library > code (the code CodeBoost is designed to optimise), but I encountered > problems with ambiguities (which was kind of expected, since some type > information was missing). Also, it seemed to be a bit too slow to be > usable for us at the moment. I expect both problems can be solved without > too much trouble. > > -otto > -- Nicolas Desprès nicolas.despres(a)lrde.epita.fr

21 years, 1 month

[ transformers-Feature request-15 ] Transformers for C

by noreply＠gforge.lrde.epita.fr

Feature request item #15, was opened at 2004-05-12 17:21 You can respond by visiting: http://gforge.lrde.epita.fr/tracker/?func=detail&atid=102&aid=15&group_id=5 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Clement Vasseur (vasseu_c) Assigned to: Nobody (None) Summary: Transformers for C Initial Comment: People are interested in a transformation framework for the C language. StrategoXT already has a C grammar, but it is only used for code generation, it is not completely standard compliant. Using the work we already invested in transformers, we could come up with such a transformation framework for the C language, with a reasonable amount of work. Any volunteer? ---------------------------------------------------------------------- You can respond by visiting: http://gforge.lrde.epita.fr/tracker/?func=detail&atid=102&aid=15&group_id=5

21 years, 2 months

104: Investigate testsuite failures 1-39

by olivier

Here is the result of my little investigation on gcc testsuite failures. abi/mangle4: template function definition. fail in afcxx-anonymous abi/mangle8: template method operator() definition. fail in afcxx-disambiguate abi/mangle12: template function definition. fail in afcxx-disambiguate abi/mangle14: abi/mangle15: template fail in afcxx-anonymous compat/init-ref2_y: operator && doesn't work. fail in afcxx-disambiguate eh/cleanup1: declaration of 4000 class attributes, sglr error: 'too many ambiguities'. expr/static_cast3: inheritance with a parameterized class. fail in afcxx-disambiguate inherit/access3: template method definition. fail in afcxx-disambiguate init/addr-const1: use of static and non-static class attribute in a struct constructor. fail in afcxx-disambiguate init/array11: C code, simple cast with a typedef type. fail in afcxx-disambiguate init/array6: char arr [2][4] = { "one", "two" }; doesn't parse. fail in afcxx-disambiguate init/copy2: init/copy3: struct s {}; s a = s (); fail in afcxx-disambiguate init/elide1: operator &&. init/empty1: strange base class initialization. fail in afcxx-disambiguate init/init-ref2: operator &&. init/new9: template use. fail in afcxx-disambiguate init/ref2: same as init/copy2. lookup/disamb1: call to a method in a base class. lookup/koenig2: same as abi/mangle8. lookup/scoped3: same as lookup/disamb1. lookup/template1: basic template function (parametrized by an int) use. opt/cfg2: fail in afcxx-disambiguate opt/cfg3: opt/cleanup1: opt/const1: these tests are too big, i don't want to investiguate further. opt/inline1: struct A {}; template <typename, typename> struct B {}; typedef B <int, int> C; fail in afcxx-disambiguate opt/local1: declaration of a pure virtual method in a inner class. fail in afcxx-disambiguate opt/mmx1: opt/nrv1: opt/nrv2: operator &&. opt/pr6713: too big test, too many problems. opt/reload1: call to 'operator <<' with 1 argument. fail in afcxx-disambiguate opt/stack1: opt/unroll1: too big, too many problems. opt/static2: similar to lookup/template1. ******************* These piece of code are valid, but fail with parse-cxx. They are related to gcc failing tests. *** int i = 1 && 1; *** int f(); int a = f (); // or struct s {}; s a = s (); *** char a[2][4] = { "one", "two" }; *** // Call to a method in a base class. struct A { void f(); }; struct C : public A { void g() { f(); }; }; *** // Declaration of a pure virtual method in a inner class. struct O { struct I { virtual bool f() = 0; }; }; *** // Call to 'operator <<' with 1 argument. struct A { void operator << (int s) {} void f() { return operator << (0); } }; *** struct A {}; struct B { B(int, const A&); }; B t(1, A()); *** // Strange base class initialization. class a {}; class c : a { c() : a(a()) {} }; *** struct A {}; template <typename, typename> struct B {}; typedef B <int, int> C; *** template <class T> struct a {}; struct b : a<int> {}; -- Les trous noirs sont les endroits ou Dieu divisa par zero.

21 years, 2 months

Announcement: ASF+SDF Meta-Environment 1.5

by Akim Demaille

21 years, 2 months

← Newer
1
...
27
28
29
30
31
32
33
34
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Transformers