Declarative programming

In computer science, declarative programming is a programming paradigm—a style of building the structure and elements of computer programs—that expresses the logic of a computation without describing its control flow.[1]

Many languages that apply this style attempt to minimize or eliminate side effects by describing what the program must accomplish in terms of the problem domain, rather than describe how to accomplish it as a sequence of the programming language primitives[2] (the how being left up to the language's implementation). This is in contrast with imperative programming, which implements algorithms in explicit steps.[3]

Declarative programming often considers programs as theories of a formal logic, and computations as deductions in that logic space. Declarative programming may greatly simplify writing parallel programs.[4]

Common declarative languages include those of database query languages (e.g., SQL, XQuery), regular expressions, logic programming, functional programming, and configuration management systems.

Definition

Declarative programming is often defined as any style of programming that is not imperative. A number of other common definitions attempt to define it by simply contrasting it with imperative programming. For example:

  • A high-level program that describes what a computation should perform.
  • Any programming language that lacks side effects (or more specifically, is referentially transparent)
  • A language with a clear correspondence to mathematical logic.[5]

These definitions overlap substantially.

Declarative programming is a non-imperative style of programming in which programs describe their desired results without explicitly listing commands or steps that must be performed. Functional and logical programming languages are characterized by a declarative programming style. In logical programming languages, programs consist of logical statements, and the program executes by searching for proofs of the statements.

In a pure functional language, such as Haskell, all functions are without side effects, and state changes are only represented as functions that transform the state, which is explicitly represented as a first-class object in the program. Although pure functional languages are non-imperative, they often provide a facility for describing the effect of a function as a series of steps. Other functional languages, such as Lisp, OCaml and Erlang, support a mixture of procedural and functional programming.

Some logical programming languages, such as Prolog, and database query languages, such as SQL, while declarative in principle, also support a procedural style of programming.

Subparadigms

Declarative programming is an umbrella term that includes a number of better-known programming paradigms.

Constraint programming

Constraint programming states relations between variables in the form of constraints that specify the properties of the target solution. The set of constraints is solved by giving a value to each variable so that the solution is consistent with the maximum number of constraints. Constraint programming often complements other paradigms: functional, logical, or even imperative programming.

Domain-specific languages

Well-known examples of declarative domain-specific languages (DSLs) include the yacc parser generator input language, QML, the Make build specification language, Puppet's configuration management language, regular expressions, and a subset of SQL (SELECT queries, for example). DSLs have the advantage of being useful while not necessarily needing to be Turing-complete, which makes it easier for a language to be purely declarative.

Many markup languages such as HTML, MXML, XAML, XSLT or other user-interface markup languages are often declarative. HTML, for example, only describes what should appear on a webpage - it specifies neither control flow for rendering a page nor the page's possible interactions with a user.

As of 2013, some software systems combine traditional user-interface markup languages (such as HTML) with declarative markup that defines what (but not how) the back-end server systems should do to support the declared interface. Such systems, typically using a domain-specific XML namespace, may include abstractions of SQL database syntax or parameterized calls to web services using representational state transfer (REST) and SOAP.

Functional programming

Functional programming languages such as Haskell, Scheme, and ML evaluate expressions via function application. Unlike the related but more imperative paradigm of Procedural programming, functional programming places little emphasis on explicit sequencing. For example, in Scheme, the order of evaluation of many kinds of sub-expressions is undefined or implicit.[6] Instead, computations are characterised by various kinds of recursive higher-order function application and composition, and as such can be regarded simply as a set of mappings between domains and codomains. Many functional languages, including most of those in the ML and Lisp families, are not purely functional, and thus allow the introduction of stateful effects in programs, though this is typically avoided when possible.

Hybrid languages

Makefiles, for example, specify dependencies in a declarative fashion,[7] but include an imperative list of actions to take as well. Similarly, yacc specifies a context free grammar declaratively, but includes code snippets from a host language, which is usually imperative (such as C).

Logic programming

Logic programming languages such as Prolog state and query relations. The specifics of how these queries are answered is up to the implementation and its theorem prover, but typically take the form of some sort of unification. Like functional programming, many logic programming languages permit side effects, and as a result are not strictly declarative.

Modeling

Models, or mathematical representations, of physical systems may be implemented in computer code that is declarative. The code contains a number of equations, not imperative assignments, that describe ("declare") the behavioral relationships. When a model is expressed in this formalism, a computer is able to perform algebraic manipulations to best formulate the solution algorithm. The mathematical causality is typically imposed at the boundaries of the physical system, while the behavioral description of the system itself is declarative or acausal. Declarative modeling languages and environments include Analytica, Modelica and Simile.[8]

Examples

Lisp

Lisp (1958) stands for "LISt Processor."[9] It is tailored to process lists. A full structure of the data is formed by building lists of lists. In memory, a tree data structure is built. Internally, the tree structure lends nicely for recursive functions.[10] The syntax to build a tree is to enclose the whitespace-separated elements within parenthesis. The following is a list of three elements. The first two elements are themselves lists of two elements:

((A B) (HELLO WORLD) 94)

Lisp has functions to extract and reconstruct elements.[11] The function car (sometimes called first) returns the first element in the list. The function cdr (sometimes called rest) returns a list containing everything but the first element. The function cons returns a list that is the concatenation of two data elements. Therefore, the following expression will return the list X:

(cons (car x) (cdr x))

One drawback of Lisp is when many functions are nested, the parentheses may look confusing.[12] Modern Lisp environments help ensure parenthesis match. As an aside, Lisp does support the imperative language operations of the assignment statement and goto loops.[13] Also, Lisp is not concerned with the datatype of the elements at compile time. Instead, it assigns the datatypes at runtime. This may lead to programming errors not being detected early in the development process.

Writing large, reliable, and readable Lisp programs requires forethought. If properly planned, the program may be much shorter than an equivalent imperative language program.[12] Lisp is widely used in artificial intelligence. However, its usage has been accepted only because it has imperative language operations, making unintended side-effects possible.[14]

ML

ML (1973)[15] stands for "Meta Language." ML is statically typed, and function arguments and return types may be annotated.[16]

fun times_10(n : int) : int = 10 * n;

ML is not parenthesis-eccentric like Lisp. The following is an application of times_10:

times_10 2

It returns "20 : int", that is, 20, a value of type int.

Like Lisp, ML is tailored to process lists, though all elements of a list must be the same type.[17]

Prolog

Prolog (1972) stands for "PROgramming in LOGic." It was designed to process natural languages.[18] The building blocks of a Prolog program are objects and their relationships to other objects. Objects are built by stating true facts about them.[19]

Set theory facts are formed by assigning objects to sets. The syntax is setName(object).

  • Cat is an animal.
animal(cat).
  • Mouse is an animal.
animal(mouse).
  • Tom is a cat.
cat(tom).
  • Jerry is a mouse.
mouse(jerry).

Adjective facts are formed using adjective(object).

  • Cat is big.
big(cat).
  • Mouse is small.
small(mouse).

Relationships are formed using multiple items inside the parentheses. In our example we have verb(object,object) and verb(adjective,adjective).

  • Mouse eats cheese.
eat(mouse,cheese).
  • Big animals eat small animals.
eat(big,small).

After all the facts and relationships are entered, then a question can be asked:

Will Tom eat Jerry?
?- eat(tom,jerry).

Prolog's usage has expanded to become a goal-oriented language.[20] In a goal-oriented application, the goal is defined by providing a list of subgoals. Then each subgoal is defined by further providing a list of its subgoals, etc. If a path of subgoals fails to find a solution, then that subgoal is backtracked and another path is systematically attempted.[19] Practical applications include solving the shortest path problem[18] and producing family trees.[21]

See also

  • Comparison of programming paradigms
  • Inductive programming
  • List of declarative programming languages

References

  1. Lloyd, J.W., Practical Advantages of Declarative Programming
  2. "declarative language". FOLDOC. 17 May 2004. Retrieved 26 January 2020.
  3. Sebesta, Robert (2016). Concepts of programming languages. Boston: Pearson. ISBN 978-0-13-394302-3. OCLC 896687896.
  4. "DAMP 2009: Workshop on Declarative Aspects of Multicore Programming". Cse.unsw.edu.au. 20 January 2009. Retrieved 15 August 2013.
  5. Chakravarty, Manuel M. T. (14 February 1997). On the Massively Parallel Execution of Declarative Programs (Doctoral dissertation). Technical University of Berlin. Retrieved 26 February 2015. In this context, the criterion for calling a programming language declarative is the existence of a clear, mathematically established correspondence between the language and mathematical logic such that a declarative semantics for the language can be based on the model or the proof theory (or both) of the logic.
  6. "Revised7 Report on the Algorithmic Language Scheme" (PDF). Scheme Working Group 1. Retrieved 2020-12-05.
  7. Archived October 23, 2007, at the Wayback Machine
  8. "Declarative modelling". Simulistics. Retrieved 15 August 2013.
  9. Jones, Robin; Maynard, Clive; Stewart, Ian (December 6, 2012). The Art of Lisp Programming. Springer Science & Business Media. p. 2. ISBN 9781447117193.
  10. Wilson, Leslie B. (2001). Comparative Programming Languages, Third Edition. Addison-Wesley. p. 220. ISBN 0-201-71012-9.
  11. Wilson, Leslie B. (2001). Comparative Programming Languages, Third Edition. Addison-Wesley. p. 221. ISBN 0-201-71012-9.
  12. Wilson, Leslie B. (2001). Comparative Programming Languages, Third Edition. Addison-Wesley. p. 230. ISBN 0-201-71012-9.
  13. Wilson, Leslie B. (2001). Comparative Programming Languages, Third Edition. Addison-Wesley. p. 229. ISBN 0-201-71012-9.
  14. Wilson, Leslie B. (2001). Comparative Programming Languages, Third Edition. Addison-Wesley. p. 241. ISBN 0-201-71012-9.
  15. Gordon, Michael J. C. (1996). "From LCF to HOL: a short history". Retrieved 2021-10-30.
  16. Wilson, Leslie B. (2001). Comparative Programming Languages, Third Edition. Addison-Wesley. p. 233. ISBN 0-201-71012-9.
  17. Wilson, Leslie B. (2001). Comparative Programming Languages, Third Edition. Addison-Wesley. p. 235. ISBN 0-201-71012-9.
  18. "Birth of Prolog" (PDF). November 1992.
  19. Wilson, Leslie B. (2001). Comparative Programming Languages, Third Edition. Addison-Wesley. p. 246. ISBN 0-201-71012-9.
  20. Wilson, Leslie B. (2001). Comparative Programming Languages, Third Edition. Addison-Wesley. p. 245. ISBN 0-201-71012-9.
  21. Wilson, Leslie B. (2001). Comparative Programming Languages, Third Edition. Addison-Wesley. p. 247. ISBN 0-201-71012-9.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.