The requirements on ECLiPSe are of two kinds: to enable such problems to be modelled simply and naturally; and to enable the resulting problem model to be solved efficiently. The separation of modelling and solving is supported in ECLiPSe by distinguishing the conceptual model, expressed as a ``pure'' logical ECLiPSe program, from the design model, which is constructed from the conceptual model by adding control to the ECLiPSe program.

This combination of requirements is difficult to satisfy - perhaps impossible if a completely general modelling language is required, suitable for every kind of application. However the applications for which ECLiPSe is designed are decision support applications involving combinatorial problems.

Logic programming is peculiarly apt for modelling problems of this kind for two reasons.

- It is based on relations
- It supports logical variables

Every predicate in a logic program defines a relation, either
explicitly as a set of facts, or implicitly in terms of rules.
We can recall the example from the [Wal97].
The predicate *meat* was defined by two facts:

meat(beef,5). meat(pork,7).whilst the predicate

main(M,I) :- meat(M,I). main(M,I) :- fish(M,I).

Variables in logic programming are logical variables. Thus it is
entirely natural to initialise the problem variables (for example by
writing *Countries* = [*A*,*B*,*C*,*D*]) and then to constrain them (for
example by writing *ne*(*A*,*B*) and so on).

We briefly compare ECLiPSe as a modelling language with formal specification languages, mathematical modelling languages, mainstream programming languages and object oriented languages.

- Formal Specification Languages
- Mathematical Modelling Languages
- Mainstream Programming Languages
- Object Oriented Languages

Wed Sep 3 18:07:19 BST 1997