ELABORAR EL PERFIL PROFESIONAL O DEL EGRESADO

Essenceoffers enumerated types and unnamed types to use during problem specification.

1 language Essence 1 . 3 2 3 f i n d x : s e t o f τ 4 such t h a t 5 x union { } = x , 6 . . .

Figure 4.16: Partial evaluation can remove the constraint at line 5.

by the user when defining the type. When enumerated types are not provided by a modelling system, integers are generally used to represent enumerations. This encoding requires the user to maintain the mapping between items and integers externally to the system. In addition to helping reduce this burden from the user, supporting enumerated types internally comes with an added benefit: Enumerated types do not support all operators of integers. Most importantly, they do not support arithmetic operators, and defining a decision variable to have an enumerated type as a domain limits the user from making mistakes such as using the decision variable in a type-incorrect way. Enumerated types support equality and inequality checks. They also support checking for ordering using the common operators: <,<=,>, and>=. Element order follows declaration order.

Unnamed types, similar to enumerated types, are generally modelled using integers in most CP modelling languages. Essenceoffers unnamed types to use when members of a

type are not named, i.e. they are freely interchangeable. They let the user avoid introducing unnecessary symmetry to the problem specification. For example, golfers in the Social Golfers Problem are interchangeable, the problem does not post any special constraints for specific golfers. Using unnamed types, Conjurehas access to the information that golfers

are interchangeable. Unnamed types only support equality and inequality checks.

Refinement of both enumerated types and unnamed types are simply mapping them to integers. Conjureuses a finite integer domain containing the correct number of elements to

4.3

Summary

This chapter described two main points. First is describing how Conjurefits into the big

picture: where does it fit as a part of a larger tool-chain. Second is the description of its internal design and architecture: the internal representation, parsing, type checking, the partial evaluator, and the two kinds of modelling transformations and how they are applied. In combination with a description of the rule language, which is the subject of the next chapter, these two chapters describe the core ideas in Conjure.

5

The Rule Language

This chapter explains the domain-specific rewrite rule language of Conjure. It starts by

giving motivation for the existence of such a language inSection 5.1. Section 5.2gives an overview of the different kinds of rules Conjureimplements. The overall structure of each

kind of rule is given inSection 5.3. In the rest of the chapter, features of the rule language are described. Section 5.4 describes a crucial part of the rule language, pattern matching.

Section 5.5defines many features and operators of the rule language. Section 5.6discusses a system called bubbling that is used mostly when a rule needs to create auxiliary decision variables andSection 5.7defines how unused names are generated during rule application and how such names can be requested in the definition of a rule.

5.1

Motivation for a rewrite rule language

Conjure converts problem specifications written in Essence into CP models written in

Essence0. In order to do so, it needs to representabstract decision variables and parameters

of an Essenceproblem specification using concrete decision variables and parameters in an

Essence0 model. Namely, Essencedomains need to be transformed into Essence0 domains,

and Essenceexpressions need to be transformed into Essence0 expressions.

The main duty of Conjureis applying transformations. It contains generic mechan-

specification it is working on. There are benefits to separating the definition and application of transformations. One benefit is that Conjureknows exactly what each transformation

can do and which parts of the AST it can modify. Another benefit is that transformations themselves do not have to implement a specific tree-walking mechanism, Conjurecan reuse

the generic tree walking mechanism for each transformation.

Conjureis implemented using the Haskell[Mar10] programming language. Therefore,

the easiest way of defining transformations would be to use Haskell. In such a setting, trans- formations would merely be Haskell functions, accepting candidate expression fragments as arguments and producing replacement expressions if a transformation is applicable. This way, rules would directly be written in terms of the internal representation, the AST, of Essence. There are both advantages and disadvantages of using Haskell to implement

transformations in Conjure. On the plus side: we would be reusing a lot of existing infra-

structure from the Haskell programming language, application of transformations would be easier since they would be simple Haskell functions written in terms of the in-memory representation. However, there are also disadvantages of using Haskell. Firstly, rules will have to be defined in terms of the in-memory representation. This is an advantage when applying rules, but a disadvantage when defining them because it creates a very tight and fragile coupling between how the internal data structures are defined and rule definitions. It also creates a higher barrier to entry, one needs to be familiar with Haskell and the actual implementation of Conjureto be able to write new transformations. Furthermore, and

maybe most importantly, definitions of transformations quickly become very verbose when a general purpose programming language is used.

Transformations in Conjureare implemented as rewrite rules. These rewrite rules are

written in a domain-specific rewrite rule language, and they use the same syntax as Essence

and Essence0 to a large extent. The rewrite rule language adds a number of new constructs;

these are described inSection 5.5.

There are many advantages of using a domain-specific rewrite rule language to encode modelling transformations. The rule language only contains those features that we need for

the purpose and nothing more. Thanks to this limited set of language constructs and its resemblance to Essence, we hope using the rewrite rule will have less cognitive overhead.

The rule language also makes it easier to extend Conjurewith new rules. Adding a new

rule does not require recompiling Conjureand it does not require writing any any Haskell

code. Probably most importantly, rules written in the rule language are decoupled from the internal representation of Essence and Essence0. This makes it easier to maintain

rules, changes to the internal data structures of Conjurewill require no change to rules

themselves.

Using a domain-specific rewrite rule language also has a few disadvantages. Firstly, the rules are interpreted rather than compiled. Compiled rules are likely to be faster; yet we chose to use a rule language because conciseness and ease of extensibility of rules were more important to us. Secondly, the rule language is not Turing-complete. Some transformations are harder, if not impossible, to write in the rule language in comparison to a Turing-complete programming language. This disadvantage does not seem to be a huge problem in practice, since we can always extend the rewrite rule language with new language constructs.

It is also important to note that having a domain-specific rewrite rule language does not mean Haskell cannot be used to define any transformations. Some transformations can be defined using Haskell, especially when defining the same transformation using the rule language is cumbersome or too slow. In practice, Conjure’s partial evaluator is

implemented using transformations defined in Haskell because of evaluation of Essence

expressions happens very often and is desired to be fast.