Abstract This paper presents a method for developinggeneric C++ software libraries from functional prototypes,based on program transformation. More precisely, the typesignatures of generic functions, i.e., functions parameterizedon types, are transformed. This transformation maps type-level expressions from functional higher-order, typed lan-guages to type-level expressions in C++. In particular, type-level functional constructs such as higher-order functions andtype constructors, are mapped to type parameters of genericsthat are constrained with appropriate concepts. The core ofthe transformation is a novel form of “defunctionalization” atthe level of types. To make the transformation retargetable,we based it on two kernel languages that can be bound todifferent functional and object-oriented languages. For thispaper, we use bindings to Haskell as front end and C++with concepts as back end. Our transformational approachpresents an alternative to a language extension and is use-ful particularly for functional prototyping where functionalfeatures are employed at specification time. We illustrate ourapproach by a case study: we show how we developed ageneric C++ library for vulnerability modeling in the con-text of global change from a functional prototype in Haskell.
D. Lincke (B)Global Climate Forum, Berlin, Germanye-mail: [email protected]
S. SchuppInstitute for Software Systems,Hamburg University of Technology, Hamburg, Germany
C. IonescuResearch Domain Transdisciplinary Concepts and Methods, PotsdamInstitute for Climate Impact Research (PIK), Potsdam, Germany
1 Introduction
In interdisciplinary research, such as climate change andeconomics, complex and complicated computer models areimportant tools. Usually their implementation in a (pos-sibly low-level) programming language is an effort ofseveral person-years. Therefore, prototypes are useful totest different designs, to improve the model on a con-ceptual level iteratively, and to avoid potential errors thatmight otherwise be apparent only after the costly stageof coding. In such an interdisciplinary setting, the prob-lems that should be analyzed with the help of the themodel are often not well-understood, or not even preciselystated.
Functional programming languages have proven helpfulfor efficient prototyping: their notation is close to mathe-matics, the language common across the disciplines, and, asshown in [18], they are very suitable for prototypical softwaredevelopment. Due to their precise and clean notation, func-tional programs allow scientists to test ideas and to developa precise understanding of the problem. Such a style of pro-gramming is referred to as exploratory programming [32],and functional programs are sometimes seen as executablespecifications [33].
Another advantage of functional languages is that, if theyare typed, they usually provide powerful type systems thatinclude function types and type constructors. As models ininterdisciplinary research typically do not aim at one stand-alone application but rather at a generic library where onecan plug together different subsystems and thus reuse thesame functionality in multiple ways, such advanced type sys-tems are essential. Type annotations do not just improve read-ability, they also allow for safe parameterization. Static typechecking detects type errors and type parameter substitutionfailures at design time.
123
D. Lincke et al.
By definition, a prototype is only a model of a softwaresystem, not the system itself. Once it has enabled the devel-opers to gain an understanding of the structure and the depen-dencies of the system, the prototype has served its purposeand may thus be discarded. However, it could also be bene-ficial to base the implementation directly on the prototype,for example, by successive refinement.
In this paper, we present a method that aims at reusingparts of functional prototypes in the actual implementationlanguage. In particular, we present a transformation for acrucial part of functional prototypes of plugin architectures:we transform type-parameterized function signatures froma functional language into a non-functional language thatsupports generic programming and concepts to constraintype parameters. Using a transformation allows for the reuseof the tricky dependencies and abstractions at the level oftypes.
We look at the function signatures as the specification ofa program that will be written in a mainstream language.The specification happens to be part of an executable proto-type that allows for easy experiments and evaluation, but forthe actual mainstream program only the signature matters.Therefore, we do not aim at the transformation of functionbodies. Our approach can thus be considered as a variation ofwhat elsewhere is called a model-based approach: the func-tional signature serves as a model and the transformationensures that this signature is preserved. Much as in any othermodel-based approach, the actual implementation still needsto be filled in. However, we argue that the implementationeffort is comparatively low once the signature is known.
Our approach assumes that one wishes to target an imper-ative or object-oriented language for the actual implemen-tation. This is due to efficiency reasons, but also due tothe reduced difficulty of interfacing with other libraries thesimulation might require. In general, the actual implemen-tation will have requirements that the prototype did nothave.
Algorithmically, the core of the transformation is a defunc-tionalization that removes higher-order function types fromfunction signatures. We present a framework for trans-forming functional, higher-order typed signatures to object-oriented interfaces. The framework consists of the transfor-mation, denoted T , two intermediate languages, called func-tional type kernel language (FTKL) and concept type kernellanguage (CTKL), and language bindings. Figure 2 illus-trates the framework.
The two intermediate languages serve two purposes:firstly, they provide a common syntax for the entities ofinterest: functional type signatures (FTKL) and concept-constrained type signatures (CTKL). Secondly, these twointermediate languages make the transformation independentfrom particular programming languages, front ends and backends provide bindings to different languages. Although, in
this paper we restrict ourselves to Haskell as the front endlanguage and C++ (with concepts) as the back end language,the related PhD thesis of one of the authors [26] presentsother language bindings.
The FTKL, is a subset of the Haskell language that cov-ers function signatures. To keep the transformation easy andindependent from Haskell, it removes some Haskell-specificsyntactic sugar (for instance for the list type constructor).It supports higher-order functions, higher kinds (type oper-ators), parameterized types, and constrained polymorphism.The CTKL, on the other hand, is inspired by the recent con-cept feature, a combination of ad hoc and constrained para-metric polymorphism [23]. Concepts are supported by manyof those languages that are today used for libraries and frame-works [12] and, therefore, provide a good common abstrac-tion. Mapping functional features of the type systemto con-cepts allows to use these functional features in languages withdifferent paradigms. As shown in [12] concepts are availablein functional, imperative, and object-orientedlanguages.
We illustrate our transformational framework using anexample from interdisciplinary research; we apply the trans-formation to implement a library for vulnerability assess-ment in the context of climate change. We describe thewhole process of developing the library, we start by usingexploratory programming to develop a mathematical modelof vulnerability assessment written in Haskell. This modelserves as a functional prototype and we show how to useour transformation to generate the function signatures for ageneric C++ library for vulnerability assessment. Finally, wesketch how we implemented the complete C++ library.
Figure 1 gives a flavor of the functional prototype forvulnerability computation. It consists of just a few linesof code, and due to its genericity the function signaturesprovide important information: type variables, type clas-ses, higher-order functions, and type constructor variablesexpress dependencies such as type identities or requirementsfor types. For such function types it is not clear at all howto express them in a non-functional language as C++, andeven after figuring out that such higher-order constructs canbe mapped to concepts manual “translation” would be rathercomplicated. Here, our automatic transformation is prefer-able over manually deriving the library design.
In summary, our contributions are the following:
• we present a method for developing generic libraries indifferent languages which covers the whole process frommathematical exploration to functional prototypes to theactual library in a possibly non-functional implementa-tion language;
• the method includes a retargetable transformation offunctional signatures that allows one to reuse the typeinformation of the functional prototype in the actualimplementation;
123
Functional prototypes for generic C++ libraries
Fig. 1 A very simplefunctional prototype of avulnerability computation, inHaskell and in FTKL
• the transformation is based on two kernel languages,FTKL and CTKL which capture the essentials of functionsignatures;
• we demonstrate how our method can be used in develop-ing a library for vulnerability computation in the contextof global change.
The paper is an extension of [29]. While the earlier confer-ence paper concentrates on technical details of the two kernellanguages and the transformation, this paper draws a biggerpicture. It explains the whole process of developing a librarywith our method and how the transformation is useful in thisprocess. The vulnerabilityassessment case study serves as anillustration for the whole method, not only for the transfor-mation. Compared to [29], additional material is, therefore,added as Sect. 3 where the vulnerability model is described,in Sect. 4 where the transformation is embedded in a work-flow to develop libraries from functional prototypes, and inSect. 6 where we describe the application of our method in thevulnerability example. Furthermore, this paper also shows inSect. 5 the rewrite rules for CTKL to concept-C++.
The remainder of the paper is organized as follows. Westart by introducing some basic notations from Haskell andC++ and afterwards, we introduce the notion of vulnerabilityand present a functional prototype of a vulnerability library.Section 4 describes our approach to develop a C++ libraryfrom such a functional prototype, and in Sect. 5 we presentthe transformation that is the core of our approach. In Sect. 6,we demonstrate our approach with the vulnerability example,in Sect. 7 we sketch other applications of our method, andSect. 8 concludes.
2 Preliminaries
As we use Haskell as the prototyping language and C++withconcepts for implementation at this point we want to give a
very short description of some of the notations used. It isworth noting already from the start that :: is used in twodifferent ways: in Haskell it is the “has type” keyword, whilein C++ it is the “scope resolution” operator.
2.1 Haskell
We use Haskell [22] for implementing a prototype of themathematical model.
Functions in Haskell consist of two parts: a function sig-nature and the function body. The signature declares thetype of a function and its syntax is f :: Context =>t1 -> t2. A function signature starts with an identifierthat stands for the name of the function followed by a doublecolon. After an optional context followed by => the functiontype is denoted byt1 -> t2wheret1 andt2 are arbitrarytypes.
As usual in Haskell, we denote function application byjuxtaposition: f a denotes the application of f to a, paren-theses are not needed. Function composition is (.) ::(b ->c) -> (a -> b)-> (a -> c) and the nota-tion [x] denotes the type for lists with elements of type x.The notation[] denotes the empty list, and(x:xs) denotesthe list composed from head x and tail xs.
2.1.1 Concepts
Concepts are linguistic means to constrain parametric poly-morphism. A concept is an abstract specification of a set of(tuples of) types where the body contains associated entities:values, functions, or types themselves. Concepts may alsoinclude equation-based axioms. Historically associated withthe standard template library (STL) in C++, concepts playan important role today in the ISO/ANSI standard librariesand the de-facto standard libraries from Boost [8] but alsoin libraries from private vendors like Adobe’s GIL. How-ever, concepts are by no means restricted to C++. Magno-
123
D. Lincke et al.
lia [3], for example, is another language where concepts arefirst-class entities. Comprehensive studies have mapped con-cept terminology to language features in a variety of lan-guages and could show that, among others, Java interfacesand Scala traits can be seen as implementations of conceptsin the object-oriented world [6,12].
Since our transformation should be easily retargetable,concepts seem to be a good choice for an intermediate lan-guage. On the other hand, they have never been used forsuch purpose and existed so far either entirely within a par-ticular programming language or in natural language only.We, therefore, define CTKL as a simple language that cap-tures the main features of concepts at the level of abstractsyntax.
For concepts, we stick to the terminology used in [12]. Weuse the term concept for an abstract specification of a set of(tuples of) types where the arity of a concept is the size ofthe tuple (the number of type parameters). Semantically, aconcept is a predicate over types. When a tuple of types sat-isfies this predicate, we say that it is a model for the concept.A concept has a number of associated entities (often calledmembers): values, functions, or types.
Concepts can not only only state requirements for types,but also for type constructors. We make frequent use ofthe concepts Monad with members functions (>>=) (pro-nounced “bind”) and return and the Functor conceptwith the member function fmap.
2.1.2 Concepts in C++
While generic programming in C++ is based on C++’s tem-plate mechanism [34] and has a long tradition, concepts arenot part of the C++ language. There is no way to declare aconcept in a program, or to declare that a particular type isa model of a concept. In standard C++, concepts are heavilyused in the design of the STL [31], however, the whole useof concepts is implicit. Explicit formulation of concepts aslanguage constructs is not possible.
C++ concepts [13,16] are an extension to C++ and its tem-plate system that introduces language support for concepts.C++ concepts were proposed for inclusion in the C++0x stan-dard [17]. However, the C++0x committee decided to removeconcepts from the draft standard, as they were not consideredto be mature enough for C++0x [15]. They are still a candidatefor inclusion in future standards, and a rudimentary versionof C++ concepts has been implemented as an experimentalcompiler [14].
The following snippet of code illustrates the use of con-cepts in C++:
The concept Function defines a predicate on a sin-gle type and requires two associated type Domain1 andCodomain and an application operator (). Thus, the con-cept specifies function types, i.e., all classes that (at least) pro-vide a mapping between two identified types. In the example,it is used to constrain the sole type parameter of the twicefunction. The requirement ensures that the parameter type isa function type. The second requirement states that this func-tion type is a homogeneous function which makes it possibleto apply the function twice. For user-defined types that fulfilla concept, the bindings for the associated entities have to beprovided in a concept mapping. However, the details of con-cept mappings are beyond the scope of this paper and can beexplored elsewhere [36].
While in the above example, requirements on the twicefunction were all given in the requires clause, conceptscan be also written “inline.” Thus,template< FunctionFun > can be written to express the Function Fun. Weuse the inline notation frequently as it signifies the “types oftypes” role of concepts.
In the C++ code, we usually omit unnecessary details suchas const qualifiers or reference (&) type modifiers—whilethese are important for performance they do not contribute tothe exposition. Finally, in template parameter lists, the key-wordsclass andtypename are freely exchangeable—thevariations in the paper are motivated by space constraints.
3 Vulnerability modeling
In the past decade, the concept of “vulnerability” has playedan important role in fields such as climate change, food secu-rity, and natural hazard studies. Vulnerability studies havebeen useful in alerting policymakers to the possibility of pre-carious situations in the future.
However, definitions of vulnerability vary: there seem tobe almost as many definitions of vulnerability as case studiesconducted. In [35], for instance, the usage of 20 definitionsof vulnerability is analyzed. An allegory frequently used todescribe the terminology is the Babylonian confusion, andthe need for a common understanding has repeatedly beenexpressed in the literature [2,21].
To overcome this confusion a formal framework wasdeveloped in [20]. The outcome of this formalization is
123
Functional prototypes for generic C++ libraries
an executable mathematical model written in Haskell. Themodel applies to those studies that “project future conditions”using computational tools and that can thus be designated ascomputational vulnerability assessment.
We use the Haskell model of vulnerability as the point ofdeparture for the implementation of a generic C++ librarywith our method. In this section, we present the Haskellmodel in a rather short fashion.
Vulnerability in global change is usually related to anentity. This entity, its current situation, and its environmentare described by a state. In vulnerability computations, thecurrent state of an entity is only a starting point, it is the evo-lution of the state over time that is the main focus of interest.A single evolution path of an entity is called a trajectory.
According to [20], a vulnerability computation consistsof three ingredients: a function possible that computesthe evolution of an entity, a harm judgement function, anda measure function that collapses the harm values of thedifferent trajectories in an overall result. The three functionshave the following signatures:
1 \!possible :: State −> F Trajectory2 harm :: Trajectory −> Harm3 measure :: F Harm −> V
Four types and one type constructor are involved: Stateis the type of the state of an entity, Trajectory is the typeof a trajectory of the evolution of an entity (for simplicity weassume Trajectory = [State], so a trajectory is justthe list of states the system takes), Harm is the type of theharm values, and V is the type of vulnerability values. F is thetype constructor that represents the structure of the evolution(e.g., a set). This constructor is a functor that describes thenature of the future computation. For example, if the futureof an entity is deterministic, one would have F = Id, theidentity functor. Then, the functionpossible computes fora given state an evolution that consists of one single trajectory.If a more sophisticated model is used to predict the futureevolution, the outcome might be a list of future trajectoriesor a probability distribution over them. In these cases, the listfunctor F = [] or a probability distribution functor F =SimpleProb (see [27]) can be used.
The three functions described above are inputs to the vul-nerability computation. Combining them gives the vulnera-bility computation:
1 vulnerability :: State −> V2 vulnerability = measure . fmap harm . possible
This computation captures the idea behind many vulner-ability definitions: we measure the harm that might be pos-sible.
Such a simple model of vulnerability has some limita-tions. Firstly, the vulnerability function just takes an
initial state as input parameter, but it should also be parame-terized over the functions measure, harm, and possible.Secondly, the function possible (as described previously)models a one-step computation (e.g., it takes an initial stateand computes the complete evolution at once). However, inmany situations a stepwise computation is preferred. Forinstance, in computational vulnerability assessments thattake into account adaptation measures, these measures usu-ally depend on the current vulnerability of the system. On theother hand, the vulnerabilityin the next time step dependson the adaptation measure taken; therefore, computing thecomplete evolution at once is not appropriate in such acase. Finally, in actual vulnerability computations interac-tions between systems are studied, and the computation of thecoevolution of systems requires a more sophisticated func-tion than possible.
In [20], structures that overcome these disadvantages areexplored. On the one hand, the multitude of systems thatmight be involved has to be represented. On the other hand,we want an easy way of computing iterations. A dynamicalsystem seems to be a promising solution for that, and it turnsout that the special notion of a monadic dynamical system(MDS) captures both aspects.
In short, an MDS is a mapping with the signature t ->(x -> m x) where m is a monad. The monad condition
makes sure that we capture different kinds of systems. Ifthe considered system is deterministic we have m = Id,for a non-deterministic system we have m = [], and for astochastic system we have m = SimpleProp.
The type t specifies the input of the system. If the MDSneeds for one transition an input of type i we have t =[i]. The MDS then computes a transition function of typex -> mx that works as follows: given an input i of type tthe MDS returns a function that computes the new state m xout of the initial state x.
There are several iteration methods for MDS exploredin [20]. One, called micro trajectory computation,micro_trj, turns out to be very useful for vulnerabilityassessments. The micro trajectory function computes a mstructure of trajectories which are lists of states of type x.Thus, a micro trajectory records all single evolution pathsincluding all intermediate states. The signature of this func-tion is
1 micro_trj :: (Monad m) =>2 (i −> (x −> m x)) −> [i] −> x −> m [x]
For a deterministic systemmicro_trj computes exactlyone trajectory wrapped in an Id type, for a non-deterministicsystem we get a list of possible trajectories, and for a stochas-tic system the function micro_trj computes a probabilitydistribution over the trajectories.
To tie back to vulnerability assessment, the functionpossible in a vulnerability computation fits the signa-
123
D. Lincke et al.
ture of the micro_trj computation for an MDS. Thus,possible can be computed as the structure of micro-trajectories of an MDS. Taking this into account we can com-pute vulnerability as:
1 vulnerability :: (Functor m, Monad m) =>2 ((i −> x −> m x), ([x] −> h),3 (m h −> v), [i], x) −> v4 vulnerability (sys, harm, measure, ts, x) =5 (measure . fmap harm . micro\_trj sys ts) x
Figure 1 shows the main part of the functional prototype.It consists of the trajectory computation for monadic systemsand the vulnerability function itself. The complete prototypecontains in addition functions for the construction of monadicsystems and for parallel and serial combination of monadicsystems.
4 Our approach
The approach we present in this paper is based on a programtransformation. However, our transformational approach dif-fers from most other approaches to the extent that we trans-form type signatures and not actual code that contains valueexpressions. As shown in the previous section, the type sig-natures we transform are function signatures with functionalhigher-order types which means that they are polymorphic,with higher-order functions and higher-order type construc-tors. The target type system is not functional: higher-orderfunctions and higher-order type constructors are not sup-ported in C++ and similar languages. It still provides con-strained polymorphism, so higher-order constructs can beexpressed with constraints on type parameters. We capturethe essentials of functional type systems in the FTKLand theessentials of non-functional but concept-enabled type sys-tems in the CTKL. They consist only of function signaturedeclarations and do not contain any expression that evaluatesto a value. Our transformation is defined between these twokernel languages.
This transformation is depicted in Fig. 2. The picturemakes explicit that the approach actually implements threestages of processing, each of them defining a separate trans-formation. The first transformation, called front end, is atransformation between the functional languages and FTKL.In the vulnerability modeling example, we use Haskell asfunctional prototyping language. As we will see, FTKL itselfresembles a subset of Haskell, so the front end transforma-
Fig. 2 Transformation T and language bindings
tion is in our case trivial and, therefore, neither formalizednor presented. The second transformation is the core trans-formation T and will be described in detail in the next sec-tion. In principle, T realizes a defunctionalization transfor-mation, performed on function signatures at the level of types.The third transformation, called back end, transforms CTKLexpressions into expressions of real programming languages.Our target language is ConceptC++, and we will describe theback end that transforms CTKL into ConceptC++ in the nextsection.
The transformation is only one step in a complete work-flow for developing generic C++ libraries from functionalprototypes. That workflow is depicted in Fig. 3: the devel-oper in the application domain writes a functional prototypeof the library or the model that should be implemented. Thisprototype is used for testing and iterative improvement of thelibrary or model. If this prototype has been finalized, partsof it can be transformed into FTKL specifications. In par-ticular, the function signatures are extracted and then trans-formed into FTKL. As already mentioned, the translationfrom Haskell into FTKL is straightforward in our case.
In the next step, the extracted FTKL specifications areprocessed by the compiler that implements the transforma-tions described below. The compiler performs two transfor-mations: first, from FTKL to CTKL according to the transfor-mation steps that are described in the next section. Secondly,CTKL is transformed into function type declarations in Con-ceptC++, according to the back end transformation. The gen-erated target language contains function signatures expressedas function type definition in ConceptC++. These functiontype definitions are constrained with predefined requirementsthat are provided by the ConceptC++ back end library andtheir functionality (application operators) has to be imple-mented manually.
Fig. 3 The architecture of our transformation system
123
Functional prototypes for generic C++ libraries
5 The transformation T
Now we introduce and describe the transformation itself.As this transformation should not depend on particular lan-guages, we abstract the essentials of function signatures inboth language families, functional and object-oriented lan-guages, in two kernel languages. These two languages cap-ture the necessary constructs to express higher-order types ina functional language or in a non-functional language withconcepts. We first introduce these two languages, afterwardswe sketch the transformation steps and describe the defunc-tionalization in detail.
5.1 The kernel languages
The source of the transformation, the FTKL, is an abstrac-tion of functional higher-order, typed languages. Syntacti-cally likening a simplified subset of the functional program-ming language Haskell, it comprises functional-style func-tion signatures. However, FTKL removes syntactic sugar,such as the special notation for list types, to provide a unifiednotation of function signatures in functional languages. Thelanguage provides type variables and contexts, thus genericfunction types, as well as type constructors and type applica-tions to construct complex parameterized types. Moreover,FTKL provides an explicit notion for annotations with kinds(“types of types”). Further it should be noted that FTKL doesnot allow expressions that evaluate to a value and not a type—values are completely unknown in FTKL. Figure 1 shows theHaskell implementation and the corresponding FTKL signa-ture of the main function of the vulnerability function fromour vulnerability model in Haskell. The vulnerability func-tion depends on a system, a harm function, a measure, anda time series of external inputs. Its type is defined in lines9–10 resp. 17–18, the body in line 11. The function dependson a number of polymorphic type parameters (i,x,h,m).One of them, m, is additionally constrained to behave likea Monad and Functor (specified elsewhere). The first threearguments, sys, harm, and measure, are all higher-orderpolymorphic functions. The remaining two arguments are thelist of time steps (List i) and an initial state x that can beconsumed by the system.
While such signatures certainly are not for the faint-hearted, they model precisely the dependencies of a functionas complex as the vulnerability function. Had its signature
been expressed using “simple” parametric polymorphismonly, its arguments would have been either over- or undercon-strained. Figure 1 also shows the division of labor betweenthe higher-order, typed signature and the actual implementa-tion: once the former has been worked out, the latter usuallyis easy to write down.
The language CTKL represents the counterpart to FTKLfor object-based languages. Like FTKL, it centers around thenotion of function signatures and type variables. However, ithas no notion of higher-order functions or parametric typeconstructors. Instead, it provides three kinds of predefinedconcepts: Functions and TypeConstructors for eacharity, and the SameType concept to enforce type parameterbindings.
Since our transformation should be easily retargetable,concepts seem to be a good choice for an intermediate lan-guage. We, therefore, define CTKL as a simple language thatcaptures the main features of concepts at the level of abstractsyntax.
Figure 4 shows the previous vulnerability signature inCTKL. In the example, fun2 represents the signaturei -> x -> m x from Fig. 1, fun3 the signature Listx -> h, and fun4 the signature m h -> v. All functionsignatures are specified with Function and SameTypeconstraints.
More details of the kernel languages, such as completeBNF grammars, are presented in the related conference paper[29] and the PhD thesis of one of the authors [26].
5.2 The transformation steps
We introduce the transformation by summarizing the fivemajor steps. This overview is meant to illustrate the mainideas of every step, and does not aim at an exhaustive pre-sentation. Therefore, we disregard in this overview details asfar as possible.
The five steps of the transformation are, in the order inwhich they are executed:
1. Uncurry type constructor application. As CTKL doesnot support curried type constructor applications, occur-rences of these have to be transformed into an uncurriedform.
2. Defunctionalization of codomain types. As CTKL pro-vides no function type, higher-order functions in a given
Fig. 4 A concept-basedsignature in CTKL
123
D. Lincke et al.
function signature have to be replaced by functionsthat do not contain any function type in its domain orcodomain type. We introduce a new function signature(and therefore a new type) for every higher-order func-tion type in the codomain of a type signature and replacethis higher-order function type by a type constructor forthe new type. We call this step codomain defunctional-ization.
3. Defunctionalization of domain types. Function types inthe domain of a function signature need to be replacedas well, but in a way different from the codomain case.For each higher-order function type, we introduce a typevariable and extend the context by constraining concepts:the type parameter itself is constrained by theFunctionconcept, andSameType concepts ensure that all domainand codomain types are “initialized” to the original types.We call this step domain defunctionalization.
4. Encoding higher kinds. While FTKL supports higherkinds of type variables at a syntactical level, in CTKLthey have to be encoded in the context. The type con-structor encoding step checks the kind of all type vari-ables and adds aTypeConstructorN requirement foreach type variable that is a placeholder for a type con-structor. The arity of the type constructor is indicated ina numeral suffix.
5. Optimizing context. The encoding of higher-order func-tions and higher kinds in the context of a function sig-nature might lead to redundancies in the requirements.Those redundancies are removed in the last step. Typeparameters are called redundant if they can be expressedby a member type of a function type parameter, andrequirements are called redundant if they encode trivialidentities.
The five steps are described in detail in [26]. Here, we con-centrate on one main operation of the transformation: thedefunctionalization of the domain of a function type. Thisalgorithm is presented in the next section.
5.3 Defunctionalization
Higher-order functions cannot be expressed in CTKL direc-tly, so they have to be replaced by other constructs. Asthe processing of higher-order functions in the domain typeand in the codomain type is different, defunctionalization isdivided into two sub-steps; we only present the defunction-alization of the domain type of a function signature here.
This domain defunctionalization is done by Algorithms1 and 2. The main idea of Algorithms 1 and 2 is to scanfor occurrences of function types in the domain of the func-tion signature. Algorithm 1 scans a function signature foroccurrences of function types in the domain (the algorithmfind_fct (a) is a helper function that returns the first
function type found in the type a, or nothing if there is nofunction type in a). For each function type found, Algorithm2 is called and introduces a type variable. Then, concepts areused to encode the type of the function replaced by the typevariable. The function concept is used to state the require-ment that the type variable is a placeholder for a functiontype, type identity requirements encode the domain and thecodomain type of the function. Thus, the context contains acomplete encoding of the function type that was replaced.
Input: An FTKL’ function signature f :: Context => a-> b
Output: A CTKL function signature TC_f :: Context’=>a’ -> b such that every function type used within a
domain type is replaced by a type variable and requirements inContext’ according to Algorithm 2.
A1. Set the counter N = 0.
A2. If find_fct (a) for f :: Context => a -> bresults in Just(c -> d) compute (a’, Context’, N’)= concept_encode_HOF(a, Context, N). Collect alltype variables from Context’, a’, and b in the parameter list< param >. Then return the CTKL function signature TC_f<param> :: Context’ => a’ -> b.
A3. Otherwise, collect all type variables from Context, a, and bin the parameter list < param >. Then return the CTKL functionsignature TC_f <param> :: Context => a -> b.
Algorithm 1:domain_defunctionalization: defun-ctionalization of the domain type of an FTKL’ function sig-nature
Applied to our example, Algorithm 1 replaces the functiontypes(i -> x -> m x),((List x)-> h), and(mh -> v) in the domain of the vulnerability functionare replaced with type parameters:
1 vulnerability <m, i, x, h, v, fun1, fun2, fun3, fun4> ::2 Functor m, Monad m,3 Function fun1, Function fun2,4 Function fun3, Function fun4,5 SameType (fun1.Domain1, x),6 SameType (fun1.Codomain, m<x>),7 SameType (fun2.Domain1, i),8 SameType (fun2.Codomain, fun1),9 SameType (fun3.Domain1, List<x>),
For every type parameter that replaces a function typethree requirements are necessary to encode the signatureof this function type. For instance, the type of the newtype parameter fun3 is encoded with the following threerequirements: First, the requirement Function fun3states that fun3 is a placeholder for a unary functiontype. Then, the SameType(fun3.Domain1List < x >)
123
Functional prototypes for generic C++ libraries
Input: An FTKL’ type t, a context C, and a counter N.
Output: A triple (t’, C’, N’), consisting of the type t’which is free from function types, a context C’ that includes C,and a counter N’. Every function type from t is replaced by atype variable. In addition C’ is extended with requirements thatencode the signature function type by using function conceptsand type identity concepts. Further, N’ is the sum of N and thenumber of replaced function types.
A1. Case distinction on the type of t:
–t1− > t2:(t’, C’, N’) = concept_encode_HOF (t1, C,N)(t”, C”, N”) = concept_encode_HOF (t2, C’,N’)Create a type variable fun#N” and replace t1− > t2with it.Let D be the number of arguments of t1. Add the requirementFunction#D fun#N” to C”.If t1 is a tuple of type (t_1, …, t_T) for every typet_i add the requirement SameType fun#N”.Domain#it_i to C”. Otherwise, add the requirement SameTypefun#N”.Domain1 t1 to C”.Return (fun#N”, C”, (N”+1)).
for i=1, …, T–Compute(t’, C’, N’) = concept_encode_HOF (t2_i,C, N).
–Set t2_i = t’.–Set C = C’.–Set N = N’.
Return (t1 < t2_1, ...,t2_T >,C,N).–otherwise:
Return (t, C, N).
Algorithm 2: concept_encode_HOF: encoding functiontypes in the domain of a function signature with concept-constrained type variables
requirement specifies the domain type of this function.Finally, the requirement SameType (fun3.Codomainh) specifies the codomain type. The resulting function sig-
nature of the vulnerability function does no longercontain function types in its domain; they are all replaced bytype variables.
5.4 The complete transformation
For a given functional specification in FTKL which con-sists of function signatures, the steps sketched and describedabove are performed in the presented order. First functionsignatures are transformed and then function signatures thatare members of type classes. For every function signature,the codomain type is defunctionalized, yielding a list of func-tion signatures. For every element of this list the domain isdefunctionalized, higher-kinded type variables are encoded,and type parameters are optimized. This finally yields a listof function signature in CTKL which can then be translatedin concept-enabled programming languages. The input andoutput parameters of the transformationT , including its func-tional specification, are listed in Fig. 5.
5.5 Translation from CTKL to C++
The transformation described above turns FTKL functionsignatures into CTKL function signatures. As both languagesare kernel languages that do not provide any capabilities toactually implement computations, implementations have tobe done in actual programming languages. However, imple-mentations are guided by function signatures, and CTKLfunction signatures can be automatically translated into sev-eral programming languages. Below, we present such a trans-lation from CTKL to concept-enabled C++. In [26], wepresent translations to other languages.
The translation from CTKL to ConceptC++ consists oftwo parts. First, we have to provide the concepts for higher-order constructs as a separate library. In Fig. 6, we list theconcepts for unary and binary functions.
There is one function concept for every arity, as shownin Fig. 6, and each function concept provides three types ofmembers:
– associated domain types (called Domain1, …) for everydomain,
– an associated codomain type (called Codomain),– and an application operator mapping elements of the
domain(s) into the codomain.
The function call operator is written in confix notion; there-fore, the syntax of a function call is f(x)where f is a unaryfunction and x an argument of its domain type. In the sameway, we provide concepts for type constructors of differentarities (see [26]).
The second part of the translation from CTKL to Con-ceptC++ are rewriting rules for types and for function signa-tures, the latter are presented in Tables 1 and 2. The rewritingof a CTKL type is straightforward and not presented in detailhere (see [26]). The rewriting of a function signature accord-ing to the rules given in Tables 1 and 2 is divided into two
123
D. Lincke et al.
Fig. 5 Specification of transformation T
Fig. 6 Function concepts in C++
procedures. First, the head of the function signature is gen-erated, followed by the generation of (parts of) the functionsignature body. The head of a function signature is rewrittenas a C++ class (using the struct keyword). Function sig-natures with type parameters are written as template classes,the context is rewritten accordingly. They start with the key-word requires, followed by the list of constraints withtheir type parameters in angle brackets.
Afterwards, the function signature body is generated. Inparticular, within the class for the function the signature rep-resents all domain types and the codomain types are defined
using thetypedef keyword. Furthermore, we write the sig-nature of the appropriate application operator in C++ syntax.
5.6 Implementation
As shown in Fig. 3, the transformation system is embedded ina workflow for developing programs or libraries from func-tional prototypes. The transformations from FTKL to CTKLand from CTKL to the ConceptC++ are implemented as acompiler, its architecture is depicted in Fig. 7. The compilerconsists of several phases, working in a pipe-and-filter man-ner. As the compiler only accepts FTKL as input, the firststage of compilation is a parser for FTKL. As FTKL is asubset of Haskell, the parser in the compiler system is basedon a Haskell parser provided in the package “Haskell-Sourcewith Extensions (haskell-src-exts)” [9], and implemented inHaskell itself. It parses FTKL and provides an abstract syntaxtree (AST) representation. The AST representation is passedon and further processed by the transformer which is imple-mented in C++. The transformer implements the transfor-mation T , or more precisely, the five steps we describedabove. It produces an abstract syntax tree of CTKL functionsignatures. These CTKL function signatures are finally trans-formed into actual ConceptC++ code. This transformation isintegrated in the compiler, it is, in principle, organized as arewriting system, that is, expressions from CTKL are suc-cessively replaced by respective language constructs in Con-
Table 1 Rewriting of a CTKL function signature head in ConceptC++
123
Functional prototypes for generic C++ libraries
Table 2 Rewriting of a CTKL function signature body in ConceptC++
The notion [|A|] stands for the rewriting of a CTKL type A
Fig. 7 The compiler and its stages
ceptC++. Finally, the generated code is written into an outputfile. The whole compiler is implemented in C++ using theSTL for generic container types and comprises about 5,500lines of code.
6 Application in vulnerability modeling
6.1 Transformation
We use the transformation to process the function signaturespresented in Fig. 1. The outcome is a translation into Con-ceptC++ along the lines of the transformation which servesas a basis for the implementation of the library. Functiontypes are encoded in a straightforward way, using severalrequirements. To illustrate this, we revisit the typei -> (x-> m x)which is frequently used to encode higher-order
functions in Fig. 1. The transformation generates concept-based requirements to encode this type in the following way:
1 template<class m, class fun1>2 requires3 Function<fun1>,4 Function<fun1::Codomain>,5 TypeConstructor<m>,6 Monad<m>,7 SameType<8 fun1::Codomain::Codomain,9 m::Apply<fun1::Codomain::Domain1>
10 >
The generation of such function signatures saves a signif-icant amount of coding that would otherwise have to be donemanually.
6.2 ConceptC++ optimization
The transformation has the major disadvantage that it is ratherhard to read, as the function signature is encoded by a collec-tion of five requirements. Further, it needs two type parame-ters to encode the type i -> (x -> m x), but actuallyone would like to express the whole type as one type para-meter with appropriate constraints. A concept that encodessuch a type would also provide a domain-specific notion atthe level of concepts. On the other hand, such verbosity iseasy to deal with: one can just encapsulate entire functiontypes that are often used within the library. Except fromfinding a name, such an encapsulation can be done automat-ically. However, up to now we have done it manually. Thetype i -> (x -> m x) is such a type that is often usedas argument for higher-order functions within the library: itencodes a monadic system, thus we introduced a concept
123
D. Lincke et al.
Fig. 8 The vulnerability computation in ConceptC++
called MonadicSystem that encapsulates the entire typeby bundling the requirements:
Using this concept in the outcome of the transformationmakes the code already much more readable. The monadicsystem concept still contains a type encoding that can befactored out itself. In this case, the type i -> (x -> mx) contains the type x -> m x that is also frequently
used in Fig. 1. This type itself can be encoded in a con-cept calledMonadicCoalgebra. TheMonadicSystemconcept then becomes simpler:
For the development of the library, we used the outputof the transformation as a base to develop a hierarchy ofconcepts that encode different function types of particularinterest for vulnerability computations with MDSs. The Con-ceptC++ transformation output is further processed manu-ally, yielding the implementation shown in Fig. 8. To improvereadability, we renamed the type parameters and used theconceptMonadicSystem as introduced above. Further, wemade the vulnerability computation more flexible by intro-ducing a type parameter for the list of controls, and we use astd::Container requirement to constrain this type para-meter which means that it can be replaced by the usual STLparameterized container types. The actual vulnerability com-putation is then similar to the Haskell version: we measurethe harm that is possible along the different trajectories ofthe evolution of the monadic system.
Further details of the formalization as well as the devel-opment process of the library are described elsewhere. In[35], we describe the formalization process and how it helpsto clarify the usage of the term vulnerability, in [24,27] weillustrate the evolution of the development process of thelibrary.
7 Other applications
To show that our transformational approach is not only usefulin the vulnerability example, we used it in other applications.
123
Functional prototypes for generic C++ libraries
Fig. 9 The function signaturesof the origami library in Haskell
In [26], we present details of three applications, all of themuse Haskell as functional prototyping language and Con-ceptC++ as implementation language. However, the natureof the examples and the usage of the transformation are quitedifferent.
Generally speaking, our approach is most useful when sig-natures capture significant information at the level of types. Itis possible to use our approach for prototypes that consist ofa number of functions with simple signatures like f :: Int-> Int but in such cases it is not superior to a reimplemen-tation “by hand”. Otherwise having generic functions withconstraints on and dependencies between type parametersour transformation is a very powerful tool as it preserves thesetricky dependencies and thus saves implementation work.Therefore, the main application domain of our method is theimplementation of generic libraries and all our applicationexamples are generic libraries.
In our first example, we use the transformation to imple-ment the library Functional C++ with and without Concepts(FCPPC). It is a foundational library and extends the Con-ceptC++ back end, as it provides basic functional operations,such as composition and currying. The functional prototypefor this library is the Haskell standard library itself and thegeneric function signatures that are transformed are takendirectly from there.
In the second example, the transformation is used toreengineer a generic Haskell library in ConceptC++. The so-called Origami library centers around a generic fixed-pointdata type and generic recursion operators for it. The librarydefines a fixed-point type and recursion operators, and weapply the transformation to the function signatures of theserecursion operators to generate the function signatures of theOrigami++ library. Figure 9 lists the function signatures ofthe four main functions of the Origami library. Again, thegenericity of these signatures makes the library a suitablecandidate for our transformation. To translate the dependen-cies between the type and type constructor variables manu-ally would be quite an effort.
Finally, in our third example we use Haskell as languagefor exploratory vulnerability modeling. As described above,we used a functional prototype of a vulnerability modelinglibrary, extracted the function signatures from this prototype,and used the transformation to generate function signaturesfor a library for vulnerability modeling with MDSs.
The C++ code of all examples is tested with the gcc com-piler [11], version 4.3, and the concept code is tested with the
ConceptGCC compiler [14] (version alpha 7). The presentedlibraries are available from the project web page [25].
8 Conclusion, discussion, and future work
In this paper, we introduced a transformational approach todevelop generic C++ libraries from functional prototypes.The approach is based on a transformation that processeshigher-order, typed functional signatures. The motivation forthis method is the use of intermediate models and functionalprototypes in scientific modeling where it is desirable totransfer parts of the prototypic model into the actual imple-mentation language. While complete transformation is nei-ther desired nor possible, we restrict ourselves to function sig-natures. Higher-order functions and polymorphic type con-structors are powerful constructs for program specificationand implementation which are routinely available in Haskell,but missing in C++. The key idea of the transformation is toexpress these constructs at the level of concepts. In particu-lar, we describe function types with a function concept andtype constructors with a type constructor concept. We havedesigned and implemented two intermediate languages anda transformation in between, so our approach is not limitedto Haskell and C++. In the related thesis [26] we show howdifferent languages can be used as back end for the transfor-mation.
The biggest practical limitation presents currently the factthat we are not able to transform higher-rank types which isnecessary if we want to apply the transformation to generictraversal libraries like SYB [28]. First experiments suggestthat such an extension might be very language specific, sothat our kernel language approach might be too general forsuch an extension.
From a theoretical point of view, the transformation hasa crucial property that is beyond the scope of that paper. Inrelated work [26,29] we define the so-called kind structureof FTKL and CTKL expressions, a structural property thatdescribes the kinds of types, type variables, and type con-structors involved in a function signature. We prove that ourtransformation preserves that kind structure. However, thereare no guarantees at the level of concrete types: type con-structors are just mapped to type constructors of the samename, with no guarantee that those types are defined at all inthe back end language. Put differently, given a concrete typeconstructor, the back end is responsible for assigning to it a
123
D. Lincke et al.
proper type from the target language. One could argue thatour transformational framework should set up constraints thatprohibit “nonsensical” mappings and enforce preservation oftype semantics.
However, any of those constraints is not only hard tofulfill—it is not even desirable. Even if it might seem naturalto map a type constructor named Int, say, to the ANSI/ISO-C++type int, one can certainly not formally argue that theC++ type int is “the same type” as, say, the Haskell typeInt coming from the front end. In addition, back end imple-mentors typically expect to have the freedom to use datastructures of their choice—very concretely, most back endswould, for example, want to implement a List type construc-tor in the front end by a faster data structure such as an Array-like type constructor.
Freedom for the implementers also explains why werestricted the transformation to signatures, and do not trans-form function bodies. Besides the fact that full automatictranslation of function bodies is hardly possible [19], it isunlikely that, at implementation level, one wanted to keepthe code structure. In the scenario of climate-change mod-eling that motivated us originally, the functional front endserves the purpose of specifying dependencies between sub-systems at type level, while the actual implementation of aclimate-change model is performance-critical and has at leastto be hand-tuned. For instance, recursion from functionalprogramming is typically replaced right away by iterativeconstructs.
9 Related work
The presented work is part of a larger research agenda onfunctional prototyping in scientific computing, starting withthe work by [4,5] who used a functional model as a proto-type for a generic parallel computing library, and continuedby [20] who used Haskell to develop the functional proto-type of vulnerability used in this paper. In [7] the benefits offunctional prototyping are discussed in detail by means of anagent-based model of exchange economies.
There is also previous work about translation of Haskellinto C++. In [37] some initial ideas for a mapping fromgeneric Haskell specifications to C++ with concepts are pre-sented, yet without providing any implementation. Our ownwork in [26], which the paper is based on, generalizes themapping by making it retargetable, formally proving its cor-rectness, and providing an implementation.
Another aspect of our work is blending functional andobject-oriented features, especially the implementation offunctional programming constructs as higher-order functionsin nonfunctional languages such as C++. As this is a rele-vant topic of practical interest, there is some previous work,including the Boost Lambda library [23], the FC++ library
[30], and the Boost Fusion library [10]. While all the previousapproaches heavily rely on C++ template meta-programming[1], we encode function types at the level of concepts. Thus,our approach is more general: it is applicable to every lan-guage that provides concepts.
Acknowledgments We thank Carlo Jaeger, Nicola Botta, and PatrikJansson for insightful comments and interesting discussions. We alsothank the editor and two anonymous reviewers for their constructivecomments, which helped us to improve the manuscript. The researchin this paper was partly supported by a grant from the European Unionresearch project ADAM under Contract Number GOCE-018476 and byGrant 0702717 from the National Science Foundation.
References
1. Abrahams, D., Gurtovoy, A.: C++ Template Metaprogramming.Concepts, Tools, and Techniques from Boost and Beyond. C++In-Depth Series. Addison-Wesley, Amsterdam (2005)
2. Brooks, N., Adger, W.N.: Country level risk measures of climate-related natural disasters an implications for adaptation to climatechange. In: Tyndall Center Working Paper, vol. 26 (2003)
4. Botta, N., Ionescu, C.: Relation-based computations in a monadicBSP model. Parallel Comput. 33(12), 795–821 (2007)
5. Botta, N., Ionescu, C., Linstead, C., Klein, R.: Structuring Distrib-uted Relation-Based Computations with SCDRC. PIK Report 103,Potsdam Institute for Climate Impact Research, Potsdam (2006)
6. Bernardy, J., Jansson, P., Zalewski, M., Schupp, S., Priesnitz, A.:Generic programming with C++ concepts and Haskell type classes:a comparison. J. Funct. Program. 20(3—4), 271–302 (2010)
7. Botta, N., Mandel, A., Ionescu, C., Hofmann, M., Lincke, D.,Schupp, S., Jaeger, C.: A functional framework for agent-basedmodels of exchange. Appl. Math. Comput. 218(8), 4025–4040(2011)
8. Boost C++ Libraries. http://www.boost.org/. Accessed 2 Oct 20139. Broberg, N.: The haskell-src-exts package. http://hackage.haskell.
org/package/haskell-src-exts. Accessed 28 Nov 201110. de Guzman, J., Marsden, D.: Fusion library homepage. http://www.
boost.org/libs/fusion. Accessed 28 Nov 201111. The GNU Compiler Collection (GCC). http://gcc.gnu.org/.
Accessed 2 Oct 201312. Garcia, R., Järvi, J., Lumsdaine, A., Siek, J., Willcock, J.: An
extended comparative study of language support for generic pro-gramming. J. Funct. Program. 17, 145–205 (2007)
13. Gregor, D., Järvi, J., Siek, J., Stroustrup, B., Dos Reis, G., Lums-daine, A.: Concepts: linguistic support for generic programming inC++. In: Proceedings of the 21st Annual ACM SIGPLAN Confer-ence on Object-oriented Programming Systems, Languages, andApplications, pp. 291–310. ACM, New York (2006)
14. Gregor, D.: ConceptGCC. http://www.generic-programming.org/software/ConceptGCC/. Accessed 2 Oct 2013
15. Gregor, D.: What happened in Frankfurt? C++-next, thenext generation of C++. http://cpp-next.com/archive/2009/08/what-happened-in-frankfurt/ (2009). Accessed 2 Oct 2013
16. Gregor, D., Stroustrup, B.: Concepts (Revision 1). Technical report.Document number: N2081=06-0151, Project: Programming Lan-guage C++. Evolution Working Group (2006)
17. Gregor, D., Stroustrup, B., Widman, J., Siek. J.: Proposed Word-ing for Concepts (Revision 8). Technical report N2741=08-0251,ISO/IEC JTC1/SC22/WG21 - C++ (2008)
18. Hudak, P., Jones, M.P.: Haskell vs. Ada vs. C++ vs. Awk vs. . . . AnExperiment in Software Prototyping Productivity. Research reportYALEU/DCS/RR-1049, Department of Computer Science, YaleUniversity, New Haven (1994)
19. Haeri, S.H., Schupp, S.: Functional metaprogramming in C++ andcross-lingual development with Haskell. In: Proceedings of the23rd Symposium on Implementation and Application of FunctionalLanguages, IFL2011 (2011)
20. Ionescu, C.: Vulnerability modelling and monadic dynamical sys-tems. PhD thesis, Freie Universität Berlin (2008)
21. Janssen, M.A., Ostrom, E.: Resilience, vulnerability and adap-tation: a cross-cutting theme of the international human dimen-sions programme on global environmental change. Glob. Environ.Chang. 16(3), 237–239 (2006) (Editorial)
22. Jones, S.P.: Haskell 98 Language and Libraries: The RevisedReport. Cambridge University Press, Cambridge (2003)
23. Järvi, J., Powell, G., Lumsdaine, A.: The lambda library unnamedfunctions in C++. Softw. Pract. Exp. 33, 259–291 (2003)
24. Lincke, D., Ionescu, C., Botta, N.: A generic library for earth sys-tem modelling based on monadic systems. In: Ehlers, M., Ehlers,M., Behncke, K., Gerstengarbe, F.- W., Hillen, F., Koppers, L.,Stroinck, L., Wächter, J. (eds.) Proceedings of the Digital earthsummit on geoinformatics 2008: tools for global change research,pp. 188–194. Wichmann, Heidelberg (2008)
25. Lincke, D.: A transformational approach to generic programming.http://www.pik-potsdam.de/members/lincke/tagp. Accessed 26June 2012
26. Lincke, D.: A transformational approach to generic software devel-opment based on higher-order, typed (HOT) functional signatures.PhD thesis, Technical University Hamburg-Harburg (2012)
27. Lincke, D., Jansson, P., Zalewski, M., Ionescu, C.: Generic librariesin C++ with concepts from high-level domain descriptions inHaskell. A domain-specific library for computational vulnerabilityassessment. In: Proceedings of the IFIP Working Conference onDomain Specific Languages, pp. 236–261 (2009)
28. Lämmel, R., Peyton Jones, S.: Scrap your boilerplate: a practicaldesign pattern for generic programming. In: Proceedings of the2003 ACM SIGPLAN International Workshop on Types in Lan-guages Design and Implementation, (TLDI ’03), SIGPLAN Not.38(3), 26–37 (2003)
29. Lincke, D., Schupp, S.: From hot to cool: transforming higher-ordertyped languages to concept-constrained object-oriented languages.In: Proceedings of the 12th Workshop on Language Descriptions,Tools and Applications (LDTA 2012), Tallinn (2012)
30. McNamara B.: Multiparadigm programming: novel devices forimplementing functional and logic programming constructs inC++. PhD thesis, Georgia Institute of Technology (2004)
31. Stepanov, A.A., Lee, M.: The Standard Template Library. Technicalreport X3J16/94-0095, WG21/N0482 (1994)
33. Turner, D.A.: Functional programs as executable specifications.In: Proceedings of a Discussion Meeting of the Royal Society ofLondon on Mathematical Logic and Programming Languages, pp.29–54. Prentice-Hall Inc, USA (1985)
34. Vandervoorde, D., Josuttis, N.M.: C++ Templates: The CompleteGuide. Addison-Wesley, Amsterdam (2002)
35. Wolf, S., Hinkel, J., Hallier, M., Bisaro, A., Lincke, D., Ionescu, C.,Klein, R.J.T.: Clarifying vulnerability definitions and assessmentsusing formalisation. Int. J. Clim. Chang. Strateg. Manag. 5, 54–70(2013)
36. Zalewski, M.: Generic Programming with Concepts. PhD thesis,Chalmers University of Technology, Gothenburg (2008)
37. Zalewski, M., Priesnitz, A., Ionescu, C., Botta, N., Schupp, S.:Multi-language library development. From Haskell type classesto C++ concepts. In: Striegnitz, J. (ed.) Proceedings of 6th Inter-national Workshop on Multiparadigm Programming with Object-Oriented Languages (2007)
