# What is the difference between control flow and control logic?

I'm trying to learn about declarative programming, and while reading the wiki it said the following:

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.

What exactly does this mean? I am struggling to find a definition that effectively differentiates the two terms, especially in the context of declarative programming. Is it just describing a type of abstraction?

P.S Would it help if i could tag this as declarative programming? I can't create the tag myself

• I added "logic programming", which I think is a reasonable near-synonym. Jan 12 '17 at 20:18

Control flow is oriented around the idea of imperative statements. What is the computer doing at this given time? What will it do next? What actions should it perform?

Declarative programming abstracts this away (or at least tries to). You're program is now not a set of instructions for the computer to follow, but a sort of specification for the problem. In order to be powerful enough to be Turing complete, these specifications are usually recursive.

The main difference is that a declarative program makes no promises about how it will be run. You state the logic, and the compiler/interpreter makes a program that fulfills that logic.

One of the most important aspects of a declarative description is that it's (relatively) standalone. A procedure in an imperative language says "do this thing to the current state". A declarative program says often will not depend on its context, or will make its context more explicit.

In practice, you can usually infer the control flow of a declarative program pretty easily, especially in strict languages like ML, F# or Elm. There's a pretty close correspondence between recursive declarations and loops, and between declarative functions and imperative procedures.

Things get fuzzier in a language like Haskell, where evaluation is lazy (you don't decide what gets run when). Or in Prolog, where there's an implicit backtracking search that the runtime does for you. You're not coding these things manually, you're simply specifying what the result should look like, not how you will get that result.

• ‘You’re not coding these things manually, you’re simply specifying what the result should look like, not how you will get that result.’ In other words, declarative programming is in the problem space (isn’t it design by contract?) while imperative programming is in the solution space. E.g. declarative statement: the square root of a non-negative real $x$ is the non-negative real $y$ such that $y^2 = x$; imperative statement: the square root of a non-negative real $x$ is approximated by applying Newton’s method with the function $y \mapsto y^2 - x$ defined on the non-negative reals. Jul 19 at 15:09
• Are SQL (e.g. INSERT INTO relation (x) VALUES (3);), HTTP (e.g. PUT /path HTTP/1.1 {"x": 3}), HTML (e.g. <!DOCTYPE html><html lang=""><title>x</title>), and CSS (e.g. h1 { font-size: 3rem; }) declarative programming or imperative programming? Jul 19 at 18:25
• @Maggyero I'd say that those are all declarative. But it's a spectrum: even in C you're not giving low-level commands to the CPU. In a sense when you say x = 3; in C, you're saying "generate the program such that after executing it, the value in memory denoted by x is 3. So in a sense all languages have declarative elements, at different levels of abstraction. Jul 19 at 18:38
• I would have thought that they are all imperative since their statements are commands (SELECT, INSERT, UPDATE, DELETE commands for SQL, GET, PUT, DELETE commands for HTTP, commands to create the DOM structure for HTML, commands to attach style to the DOM structure for CSS), not constraints (e.g. preconditions, postconditions, or invariants). Jul 19 at 20:11