Static Expansion vs Procedural Code Generation in Modelling Languages for Constraint Programming Julien Martin and Thierry Martinez and Fran¸cois Fages EPI Contraintes, INRIA Paris-Rocquencourt, BP105, 78153 Le Chesnay Cedex, France. Julien.Martin@inria.fr Thierry.Martinez@inria.fr Francois.Fages@inria.fr http://contraintes.inria.fr/ Abstract. To make constraint programming easier to use by non-programmers, a lot of work has been devoted to the design of front-end modelling languages using logical and algebraic notations instead of programming constructs. The transformation to an executable constraint program can be performed by fundamentally two compilation schemas: either by a static expansion of the model in a flat constraint satisfaction problem (e.g. Zinc, Rules2CP, Essence) or by generation of procedural code (e.g. OPL, Comet). In this paper, we compare both compilation schemas. For this, we consider the rule-based modelling language Rules2CP with its static exansion mechanism and describe with a formal system a new compilation schema which proceeds by generation of procedural code. We analyze the complexity of both compilation schemas, and present some performance figures of both the compilation process and the generated code on a benchmark of scheduling and bin packing problems. 1 Introduction Constraint programming is a programming paradigm which relies on two compo- nents: a constraint component which manages posting and checking satisfiability and entailment of constraints over some fixed computational domain, and a pro- gramming component which makes it possible to state the constraints of a given problem and define a search procedure for solving it. To make constraint pro- gramming easier to use by non-programmers, a lot of work has been devoted to the design of front-end modelling languages using logical and algebraic nota- tions instead of programming constructs, e.g. OPL[13,7], Comet [9] , Zinc [10,3], Essence [6] or Rules2CP [4,5,2]. Such modelling languages for constraint programming offer a high-level of abstraction for stating constraint problems, and rely on default, possibly pa- rameterized, search strategies. The transformation to an executable constraint program can be performed by fundamentally two compilation schemas: either by a static expansion of the model in a flat constraint satisfaction problem, or by generation of procedural code. The first schema by static expansion has