The purpose of this note is to incite discussion on the list. There
was a great deal of discussion on this very point during the face to
face meeting at ICCAD, and it is hoped that this note will cause some
of the same points, and some additional points, to be brought up on
the list. This is being done as part of the DCWG / SLDL joint
subcommittee on the language.
The primary considerations in the decision between an executional
versus a declarative style (and definition) for a constraint language
are centered in how the language will be used. And the general
guideline is sufficiently clear that it sounds like something close to
motherhood and platitudes: if the purpose is to calculate the values
for the constraints and to describe how the constraints are to be
checked, then an executional style is best; if the purpose is to state
constraints independent of any given implementation, then the
declarative style is best.
Within this, there are several ways of approaching the question:
"sub-topics", as it were. First, we can make some specific technical
statements that are undeniably true; however, they may not make any
difference in the practical world.
1) Declarative languages can state things that executional languages
cannot. In particular, executional languages are limited to Turing
computable functions, while declarative languages are not.
2) The direct corollary to the above statement: declarative languages
can state constraints that cannot be checked. The converse
statement for an executional language needs to be stated more
carefully. It is always possible to write incorrect specifications
in an executional language that do not terminate, or that yield an
incorrect answer (just as it is possible to define incorrect
constraints in a declarative language). The converse should
probably be stated as follows: it is an intrinsic quality of
executional specifications that they terminate with the correct
answer. Intuitively, executional specifications can be executed; a
tool can use them to produce values and check that constraints are
satisfied. There is no guarantee that this is true for declarative
languages.
In practice, the technical points mean little. It is unlikely that
the executional limit will impose great restrictions on constraint
specification, and fairly large subsets of a fully declarative
language can be executional. Examples of the latter are functional
languages (Haskell, ML, Erlang, Clean) and logic languages (Prolog,
OBJ3, Maude).
Also in practice, the question of which language to use as a "base"
for the language may be more important than that of executional versus
declarative. For example, among the present exemplars we have is one
that is based on TCL. Scripting languages have a great deal of
practical appeal in that they can be connected directly to various
tools, and these tools can both produce values for the constraints and
actually check the constraints. If the committee chooses to go in
this direction, th question of which scripting language to use becomes
a vital --- and controversial --- one. Several other candidates
propose themselves, such as Python.
The primary requirement in this area may not be a "scripting" language
per se, but the ability to call external tools. If this is the
consideration, then any language with connections to C or Java becomes
a candidate (including C, C++, and Java; let's not omit the obvious).
However, even for this requirement we may wish to examine a more
language independent solution. Haskell has a connection to any
routine defined via IDL through the HaskellDirect package. Moreover,
any language with a similar connection mechanism can be used for this
as well, even a fully declarative one.
In the final analysis, the question comes down to what we want our
constraint descriptions to look like:
1) How much like an existing language should we make them look? Like
C or Java? Should we just use C or Java?
2) How mathematically sound do we want the descriptions to be? Like
it or not, C and Java are not as easy to make mathematically
precise as declarative languages are.
3) Do we want our constraints to look like statements of the
constraints, or like mechanisms for checking the constraints?
Which is more understandable? Which is more useful?
Having made an effort to remain somewhat neutral, I am going to now be
personally biased and give my own opinion: I like to think of
constraints as things that describe the system being constrained
rather than as procedures for checking the constraints. Therefore, I
come down heavily on the side of declarative constraints. I also want
the correspondance between the DCWG constraint language and the SLDL
constraint language to be as close as possible, and it is fairly sure
that the SLDL constraint language will be declarative in nature.
However, the purpose of this note is to create discussion, not to
convince people; thus, I hope the above opinion will generate
discussion more than make people fall in line. Comments, questions,
and flames are all, of course, welcome.
Dave Barton <*>
dlb@averstar.com )0(
http://www.averstar.com/~dlb