Syntactic Sugar Support for Advanced C++ Constructs Thomas Largillier Technical Report no0515, July 2005 revision 933 The LRDE is developing two libraries, Olena [4] and Vaucanson [7] which both have high requirements concerning code efficiency and speed. They have to use many paradigms based on efficiency. Writing efficient code becomes quickly equivalent to writing cryptic code. Then the written is almost write-only and obviously this is not a good point concerning code writing and the maintainability of an application. Here we provide a method to help the developers by adding sugar to C++. This method is based on island grammars and developted with the Stratego/XT [10] tools. Le LRDE développe deux bibliotheques, Olena et Vaucanson, qui sont tres concernees par les aspects de genericite de de performance. Elles utilisent de nombreux paradigmes amenant ces deux aspects. Ecrire du code efficace et generique revient rapidement a ecrire du code assez cryptique. Le code ecrit est qua- siment illisible ce qui evidemment freine son ecriture et diminue sa maintenabilite. Ici est presentee une methode pour aider les developeurs en ajoutant du sucre au C++. La methode est basee sur l’ecriture d’une grammaire a iles et developpee avec l’environnement Stratego/XT. Keywords Island grammars, program transformation, syntactic sugar 2 Laboratoire de Recherche et Développement de l’Epita 14-16, rue Voltaire – F-94276 Le Kremlin-Bicêtre cedex – France Tél. +33 1 53 14 59 47 – Fax. +33 1 53 14 59 22 [email protected] – Transformers 3 Copying this document Copyright c 2005 LRDE. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Sections being just “Copying this document”, no Front- Cover Texts, and no Back-Cover Texts. A copy of the license is provided in the file COPYING.DOC. Contents 1 Cxx syntax limitations 6 1.1 Overview of the syntax .................................. 6 1.2 Limitations ......................................... 6 1.3 Example .......................................... 7 2 Island grammars 8 2.1 Presentation ........................................ 8 2.1.1 Definition ..................................... 8 2.1.2 Concepts ...................................... 9 2.2 Interests .......................................... 9 2.2.1 General ....................................... 9 2.2.2 Desugaring .................................... 9 2.3 Use ............................................. 10 2.3.1 Grammar extensions ............................... 10 2.4 Drawbacks ......................................... 10 3 Cxx_desugar 11 3.1 Tools ............................................ 11 3.1.1 eSDF ........................................ 11 3.1.2 Stratego ...................................... 12 3.1.3 SGLR ........................................ 13 3.2 The pipeline ........................................ 14 3.3 Sugars provided ...................................... 15 3.3.1 The meta tag .................................... 15 3.3.2 Virtual typedefs .................................. 15 3.4 Future work ........................................ 18 3.4.1 More sugar .................................... 18 3.4.2 More checking .................................. 19 4 Bibliography 21 5 CONTENTS Introduction The Transformers project [8] was born in the LRDE to help the developers working on Olena [4] and Vaucanson [7]. Indeed both of these projects, developed in C++ language, are using several notions to improve code efficiency and speed. Most of these notions were even created in the LRDE for the need of being efficient and remaining as generic as possible. The major drawback of these paradigm is, since they were invented very recently, there is no language that supports them in a native way. This obliges the developers to find some syntactic constructs to express these notions in C++. Actually finding C++ constructs corresponding with the ideas is not the most difficult part since the developers are very familiar with this language. The problems are the constructs themselves. Actually they are often heavy, unnatural and complex. This increases the developing phase of the libraries since the programmer has more code to write. Moreover new programmers joining the LRDE each year loose a relevant time understanding these notions and learning how to write efficient code using these paradigms. Here we provide some syntactic sugar to C++ in order to simplify the writing of efficient and generic code. This sugar was suggested by Thierry Géraud, Olena team leader. Since they are using many static paradigms to increase the speed of their libraries, the source code becomes quickly a huge amount of "template" methods and values. This is why they need some constructs syntactically and semantically clearer. The sugar and the desugaring process are based on an island grammar. This work should obviously be done in a short amount of time. The time saved writing light constructs should not be lost in the desugaring process. We also have to take care of our own efficiency in ad- dition of the effectiveness of the produced code. Since we are only realising source to source tranformations and not compiling the source given to the program. Chapter 1 Cxx syntax limitations 1.1 Overview of the syntax The C++ is a language where you can express almost everything thanks to the mixing of two paradigms: the Object Oriented Paradigm (OOP) and the Generic Programming Paradigm (GP). Both of these paradigms are well supported in the language. Thanks to the inheritance given by OOP and the template keyword provided for GP, the last one providing generic code and meta-computation. Olena and Vaucanson are able to express almost everything they want in this language since it is less restrictive than other popular languages (Java, Eiffel, . ) and also for its efficient compile- time computation system provided by the template parameters for classes and functions. Even if we are able to express many paradigms in C++, the problem here is that there are only few mechanisms to express these notions in this language, basically only hierarchies and the template keyword. Then developers need to be very clever and asticious to find the good constructs according to their ideas, trying to keep a link between the syntax and the semantics. This could be hard some time but does not represent the major problem. Here the most important is that these constructs are mostly heavy, unnatural and complex. The reason is the small amount of syntatic constructs offered to the developer. Then we provide more syntactic constructs in order to help developers to clarify their code and add some semantic. The idea is to bring closer the semantic and the syntax. 1.2 Limitations If these things are considered as limitations, even if programmers can express every notion in C++, it is because they really slow down the developing process of the application and reduce the maintainability of the project. These limitations are really induced by the syntax and not the paradigms because if we imag- ine a clearer syntax for these notions that could help the developer in writing his code, this will reduces the writing time and increases the maintainability of the project. These limitations should not be ignored, indeed, when new students are joining the LRDE each year, they lose a relevant amount of time to learn the paradigms and how to write code 7 Cxx syntax limitations using them. With a clearer syntax, the time spent to learn how to write efficient code could be reduced. 1.3 Example This is an example of code that has become cryptic. 1 # ifndef OLENA_CORE_ABSTRACT_IMAGE_BY_DELEGATION_HH 2 # define OLENA_CORE_ABSTRACT_IMAGE_BY_DELEGATION_HH 3 4 # include <oln/core/box.hh> 5 # include <oln/core/abstract/image_entry .hh> 6 7 8 namespace oln { 9 10 11 / / fwd d e c l 12 namespace a b s t r a c t { 13 template <typename I, typename E> s t r u c t image_by_delegation ; 14 } 15 16 // super type 17 18 template <typename I, typename E> 19 s t r u c t set_super_type < abstract::image_by_delegation< I, E> > 20 { typedef abstract ::image_entry<E> ret; }; 21 template <typename I, typename E> 22 s t r u c t set_super_type < abstract :: image_by_delegation<const I , E> > 23 { typedef abstract ::image_entry<E> ret; }; 24 25 / / p ro p s 26 27 template <typename I, typename E> 28 s t r u c t set_props < category ::image, abstract ::image_by_delegation<I , E> > 29 : public get_props< category::image, I > 30 { 31 typedef I delegated_type; 32 // FIXME: what about storage_type? 33 } ; 34 35 template <typename I, typename E> 36 s t r u c t set_props < category ::image, abstract :: image_by_delegation<const I , E> > 37 : public get_props< category::image, I > 38 { 39 typedef I delegated_type; 40 typedef is_a<abstract :: readonly_image> image_constness_type; 41 // FIXME: what about storage_type? 42 } ; 43 44 //... 45 46 47 # endif / / ! OLENA_CORE_ABSTRACT_IMAGE_BY_DELEGATION_HH Figure 1.1: Cryptic C++ code Chapter 2 Island grammars 2.1 Presentation 2.1.1 Definition Definition 1 ([6]) An island grammar is a grammar that consists of two parts: • detailed productions that describe the language constructs that we are particularly interested in (so called islands) • liberal productions that catch the remainder of the input (so called water). 1 module water 2 imports layout 3 exports 4 s o r t s Water Input Chunk 5 6 context−free syntax 7 Chunk∗ −> Input { cons ( "C" ) }