Re: Declarative constraints in practical terms

ralphbecket_at_gmail.com wrote:
> dawn wrote:
> > Mikito Harakiri wrote:
> > > ralphbecket_at_gmail.com wrote:
> > > > Rougly speaking, a declarative logic language should
> > > > - not have side effects;
> > > > - be order independent (i.e., respect the commutativity
> > > > of conjunction and disjunction and be sound w.r.t.
> > > > negation, if supported); and
> >
> > I'm not sure I fully understand this -- can you provide an example of
> > how an imperative language would not meet this requirement?
>
> Sure (examples are in C):
> - destructive assignment is a side effect, as in
>
> main(int argc, char **argv)
> {
> int x = 0; printf("%d", x);
> x = x + 1; printf("%d", x);
> }
>
> will print "01", so the assignment statement definitely has a side
> effect.
>
> - If you have side effects then it's easy to violate the commutativity
> of
> conjunction, as in
>
> int x;
>
> int p(void) { return x == 0; }
>
> int q(void) { x = 1; return 1; }
>
> main(int argc, char **argv) {
> x = 0; if(p() && q()) printf("a");
> x = 0; if(q() && p()) printf("b");
> }
>
> This program will print "a", but not "b", so the order of conjunction
> matters, therefore the commutativity of conjunction is not preserved.

Got it, thanks.

> >
> > > > - functions (if any) should be referentially transparent.
> >
> > So you cannot write functions that take keyboard input, right? How
> > would a declarative language take user input?
>
> Ah, I meant `function' in the mathematical sense of a many-to-one
> relation (with no side effects).

I understand in concept, wasn't sure how this worked out in a language requiring functions that take keyboard input. But no need to respond, I'm not up to speed in this area.

> It is quite possible to handle IO (and things that are essentially
> imperative in a pure language) without destroying the declarative
> semantics of the language. Haskell uses monads while Mercury
> uses uniqueness. How those techniques work would be a post
> in itself, but the gist of both ideas is that functions that "do" IO
> are represented as functions from states-of-the-world to
> states-of-the-world (i.e., the state-of-the-world appears as an
> explicit argument).
>
> > > > Have a look at Mercury for an example of a pragmatic,
> > > > general purpose, high performance declarative
> > > > programming language.
> > >
> > > In a truly declarative language predicates shouldn't have the "mode"
> > > declarations
>
> Mikito is wrong here: the modes in Mercury are orthogonal to the
> declarative semantics. Modes constrain the operational semantics of
> the compiled program, but the denotational semantics remain
> unaffected - you will never get a result from a Mercury program that
> is not also a model of its declarative reading.
>
> > Now I'm trying to sort out the difference between declarative and
> > imperative as well as the reason I would want to use one over the
> > other.
>
> Declarative = "what".
> Imperative = "how".

Sure, but there's a ton of what in imperative languages and there seems to be how in declarative languages too

> A spreadsheet is a declarative language: you tell it what to compute,
> not how to compute.

OK, helpful.

>
> C/Java/etc. are imperative languages: you tell the computer how it
> should compute, but not what it is computing.
>
> At the risk of making a weak argument, a declarative program is a
> mathematical statement, and mathematics is the most successful
> means of modelling the world yet invented!

Very powerful in many ways. Language is another very powerful means of modeling, perhaps more likely to end a war, for example.

> On the other hand, there
> is no useful mathematical intepretation of an imperative program.

>From a practical standpoint, what does this give us? Is there any
evidence that there are fewer bugs in software written using declarative languages?

> > All declarative languages have these features that are not found in
> > imperative languages:
> >
> > Would the list completing this sentence be Ralph's list above?
>
> In a nutshell, if your language is just a special syntax for (some)
> mathematics, then it's declarative.

OK, that is helpful.

> In mathematics there are no
> side effects and the order in which you evaluate things doesn't
> matter. (Order of evaluation is something compilers should worry
> about; programmers should worry about writing programs that
> work and meet the spec.)

I've read a lot of the "what not how" treatments (although it has been a while) but I don't fully grasp the implications in practical terms. I gather that the downside of programming languages such as Java compared to declarative languages would be related to the quality of the software written in the language and/or the speed with which one can write quality code. But if there is a significant difference in quality and cost and if declarative languages can be general purpose languages, then why are so many people still coding with "imperative" languages? I think there must be good reasons. What are the problems of using declarative languages?

Thanks. --dawn Received on Wed Mar 01 2006 - 16:07:50 CET