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.
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 (meaning ``main course'') was defined by two rules:
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.