A style of programming that concentrates on ''what'' to do, rather than ''how'' to do it.
Contrast with [imperative programming].

Some examples of declarative programming languages:
   * [Functional programming] languages, like [Haskell], ML, etc.
   * [Logic programming] languages, like [Prolog].
   * Various rule-based languages, such as [CLIPS] are primarily declarative, but are often used in a stateful manner.
   * Various procedural markup languages, such as '''compose''' ([Multics]) and the [Unix] '''*roff''' family (nroff, troff, etc.)), are imperative.
   * Various descriptive markup languages, such as [HTML] and [SGML] (from which [XML] was derived) are declarative (ish -- again, this is often not the case in practice).
[XSLT] could indeed be called an XML-based, declarative and functional programming language.
----
[SYStems] I really don't know why no one ranted about this before, but when I tell tcl to compute
 puts "Hello World!" stdout

I dont care how it does it, this is what '''How to think like a CS''' [http://www.ibiblio.org/obp/thinkCSpy/chap05.htm] books call leap of faith   and this is why, I don't know why people speak as if only declaritive programming hold any particularity in this! 

The way I see it, declarative language are almost always domain specific [Sql] and [XSLT], being domain specific, they can also be viewed as higher level programming languages, i.e. they have highly crafter syntax/construct to support their domain specific operation, which make em easier to use when performing these operation, but highly crippled outside their domain, if at all usuable.

A nice thing about Tcls' every script line is a command, is that you can hghly crafted syntax without loosing the general purposeness of the language! All Tcl control structure facilities are regular commands.

[NEM] Sure, you always rely on a computer to interpret the instructions you give it, and declarative languages are also giving the computer instructions. For instance, to illustrate, here is a declarative program which describes a book:

 book {
   title "Godel, Escher, Bach: an eternal golden braid"
   author "Douglas Hofstadter"
   isbn "0-14-028920-8"
   publisher "Penguin"
   year 1979
 }

You can view that fragment of my new Book programming language in one of two ways:

   * As a description of a book -- the ''declarative'' view;
   * As a set of instructions that, when executed, build up a graphical user interface to edit the book's details -- an ''imperative'' view.

To illustrate the second view, here is a little interpreter for my Book language, which does exactly that:

 proc book details {
  toplevel .book
  foreach {name value} $details {
    grid [label .book.$name -text [string totitle $name]: -anchor e]\
         [entry .book.v_$name -textvariable ::book($name)] -sticky ew
    set ::book($name) $value
  }
  grid [button .book.ok -text "OK" -width 8 \
        -command { parray ::book; destroy .book }] \
       [button .book.can -text "Cancel" -width 8 \
        -command { destroy .book }] -sticky e
  grid columnconfigure .book 1 -weight 1
 }

When you run it, you get a window with fields for editing data about a book. Note that my little book interpreter proc is very imperative in style -- it's all about actions that have effects. It's certainly useful to be able to program imperatively, but a good style of programming (IMO), is to move as much towards writing a little descriptive language that describes your problem domain, and then writing code to interpret that (declarative) description. This is really saying nothing much more than that separating interface and implementation is a good thing, and that Tcl has some pretty powerful facilities for making abstract interfaces that concisely describe your problem.

----
[[ [Category Concept] ]]