View source for Endogeneity (applied statistics)

In [[computer science]], '''function composition''' (not to be confused with [[object composition]]) is an act or mechanism to combine simple [[subroutine|function]]s to build more complicated ones. Like the usual [[function composition|composition of functions]] in [[mathematics]], the result of each function is passed as the argument of the next, and the result of the last one is the result of the whole.

Programmers frequently apply functions to results of other functions, and almost all programming languages allow it.  In some cases, the composition of functions is interesting as a function in its own right, to be used later.  Such a function can always be defined but languages with [[first-class functions]] make it easier.

The ability to easily compose functions encourages [[code refactoring|factoring]] (breaking apart) [[subroutine|functions]] for maintainability and [[code reuse]].  More generally, big systems might be built by composing whole programs.

==Composing function calls==
For example, suppose we have two [[function (mathematics)|functions]] <math>f</math> and <math>g</math>, as in <math>z=f(y)</math> and <math>y=g(x)</math>.  Composing them means we first compute <math>y=g(x)</math>, and then use <math>y</math> to compute <math>z=f(y)</math>.  Here is the example in the [[C (programming language)|C language]]:

<source lang="c">
    float x, y, z;
    // ...
    y = g(x);
    z = f(y);
</source>

The steps can be combined if we don't give a name to the intermediate result:
<source lang="c">
    z = f(g(x));
</source>

Despite differences in length, these two implementations compute the same result.  The second implementation requires only one line of code and is colloquially referred to as a "highly composed" form.  Readability and hence maintainability is one advantage of highly composed forms, since they require fewer lines of code, minimizing a program's "surface area".<ref>{{harvtxt|Cox|1986}}, pp. 15–17</ref> DeMarco and Lister empirically verify an inverse relationship between surface area and maintainability.<ref>{{harvtxt|DeMarco|Lister|1995}}, pp. 133–135.</ref> On the other hand, it may be possible to overuse highly composed forms.  A nesting of too many functions may have the opposite effect, making the code less maintainable.

In a [[stack-based language]], functional composition is even more natural: it is performed by [[concatenation]], and is usually the primary method of program design. The above example in [[Forth (programming language)|Forth]]:
 g f
Which will take whatever was on the stack before, apply g, then f, and leave the result on the stack.  See [[function composition#Alternative notations|postfix composition notation]] for the corresponding mathematical notation.

==Naming the composition of functions==
Now suppose that the combination of calling f() on the result of g() is frequently useful and we want to name foo() and use it as a function in its own right.

In all languages, we can define a new function implemented by composition.  Example in [[C (programming language)|C]]:

<source lang="c">
    float foo (float x) { 
        return f(g(x));
    }
</source>

(the long form with intermediates would work as well.)  Example in [[Forth (programming language)|Forth]]:

    : foo g f ;

In languages such as [[C (programming language)|C]], the only way to create a new function is to define it in the program source, which means that functions can't be composed at [[Run time (program lifecycle phase)|run time]].

==First-class composition==
In functional programming languages, function composition can be naturally expressed as a [[higher-order function|higher-order]] function or operator.  In [[Haskell (programming language)|Haskell]], the example given above becomes:
 foo = f . g
using the built-in composition operator (.), which can be read as ''f after g'' or ''g composed with f''.

The composition operator itself can be defined in Haskell using a [[lambda expression]]:
<source lang="haskell">
 (.) :: (b -> c) -> (a -> b) -> a -> c
 f . g = \x -> f (g x)
</source>
The first lines describes the type of (.) - it takes a pair of functions and returns a function.
Note that Haskell doesn't require specification of the exact input and output types of f and g,
only the relations between them (f must accept what g returns).  This makes (.) a [[polymorphism (computer science)|polymorphic]] operator.

Variants of [[Lisp (programming language)|Lisp]], especially [[Scheme (programming language)|Scheme]], the [[homoiconic|interchangeability of code and data]] together with the treatment of functions lend themselves extremely well for a recursive definition of a [[variadic]] compositional operator.

<source lang="Scheme">
(define (compose . fs)
  (if (null? fs) (lambda (x) x) ; if no argument is given, evaluates to the identity function
      (lambda (x) ((car fs) ((apply compose (cdr fs)) x)))))

; examples
(define (add-a-bang str)
  (string-append str "!"))

(define givebang 
  (compose string->symbol add-a-bang symbol->string))

(givebang 'set) ; ===> set!

; anonymous composition
((compose sqrt negate square) 5) ; ===> 0+5i
</source>

In [[JavaScript]] we can define it as a function which takes two functions f and g, and produces a function:
<source lang="JavaScript">
 function o(f, g) {
  return function(x) {
   return f(g(x));
  }
 }
</source>

In [[Python (programming language)|Python]], a way to define the composition for any group of functions, is using [[fold (higher-order function)|reduce]] function (use functools.reduce in Python3):

<source lang="Python">
def compose(*funcs):
    """Compose a group of functions (f(g(h(..)))) into a single composite func"""
    return reduce(lambda f, g: lambda *args, **kwargs: f(g(*args, **kwargs)), funcs)

# Example
f = lambda x: x+1
g = lambda x: x*2
h = lambda x: x-3

# Call the function x=10 : ((x-3)*2)+1 = 15
print (compose(f, g, h))(10)</source>

==Research survey== 
Notions of composition, including the [[principle of compositionality]] and [[composability]], are so ubiquitous that numerous strands of research have separately evolved.  The following is a sampling of the kind of research in which the notion of composition is central.

*{{harvtxt|Steele|1994}} directly applied function composition to the assemblage of building blocks known as '[[monad (functional programming)|monads]]' in the [[Haskell (programming language)|Haskell programming language]].
*{{harvtxt|Meyer|1988}} addressed the [[code reuse|software reuse]] problem in terms of composability.
*{{harvtxt|Abadi|Lamport|1993}} formally defined a proof rule for functional composition that assures a program's safety and liveness.
*{{harvtxt|Kracht|2001}} identified a strengthened form of compositionality by placing it into a [[computational semiotics|semiotic]] system and applying it to the problem of structural [[ambiguity]] frequently encountered in [[computational linguistics]].
*{{harvtxt|van Gelder|Port|1993}} examined the role of compositionality in analog aspects of natural language processing.
*According to a review by {{harvtxt|Gibbons|2002}}, formal treatment of composition underlies validation of component assembly in visual programming languages like IBM's Visual Age for the [[Java (programming language)|Java]] language.

==Large-scale composition==
Whole programs or systems can be treated as functions, which can be readily composed if their inputs and outputs are well-defined<ref>{{harvtxt|Raymond|2003}}</ref> [[pipeline (Unix)|pipelines]] allowing easy composition of [[filter (Unix)|filters]] were so successful that it become a [[pipeline (software)|design pattern]] of operating systems.

[[imperative programming|Imperative procedures]] with side effects violate [[Referential transparency (computer science)|referential transparency]] and therefore are not cleanly composable.  However if you consider the "state of the world" before and after running the code as its input and output, you get a clean function.  Composition of such functions corresponds to running the procedures one after the other.  The [[monad (functional programming)|Monads]] formalism uses this idea to incorporate side effects and I/O into functional languages.

== See also ==
* [[Functional decomposition]]
* [[Implementation inheritance]]
* [[Inheritance semantics]]
* [[Pipeline (Unix)]]
* [[Iteratee]]
* [[Principle of compositionality]]
* [[Virtual inheritance]]

==Notes==
{{reflist}}

==References==
*{{citation
 | last1 = Abadi | first1 = Martín | author1-link = Martín Abadi
 | last2 = Lamport | first2 = Leslie | author2-link = Leslie Lamport
 | doi = 10.1145/151646.151649
 | issue = 1
 | journal = ACM Transactions on Programming Languages and Systems
 | pages = 73–132
 | title = Composing specifications
 | url = http://research.microsoft.com/users/lamPort/pubs/abadi-composing.pdf
 | volume = 15
 | year = 1993}}.
*{{citation
 | last = Cox | first = Brad | author-link = Brad Cox
 | isbn = 978-0-201-54834-1
 | location = Reading, MA
 | publisher = Addison-Wesley
 | title = Object-oriented Programming, an Evolutionary Approach
 | year = 1986}}.
*{{citation
 | last = Daume | first = Hal, III
 | title = Yet Another Haskell Tutorial
 | url = http://en.wikibooks.org/wiki/Haskell/YAHT}}.
*{{citation
 | last1 = DeMarco | first1 = Tom | author1-link = Tom DeMarco
 | last2 = Lister | first2 = Tim
 | contribution = Software development: state of the art vs. state of the practice
 | editor-last = DeMarco | editor-first = Tom | editor-link = Tom DeMarco
 | isbn = 0-932633-34-X
 | location = New York, NY
 | publisher = Dorset House
 | title = Why Does Software Cost So Much, and other puzzles of the Information Age
 | year = 1995}}.
*{{citation
 | last1 = van Gelder | first1 = Timothy | author1-link = Tim van Gelder
 | last2 = Port | first2 = Robert
 | contribution = Beyond symbolic: prolegomena to a Kama-Sutra of compositionality
 | editor1-last = Honavar | editor1-first = Vasant | editor1-link = Vasant Honavar
 | editor2-last = Uhr | editor2-first = Leonard | editor2-link = Leonard Uhr
 | publisher = Academic Press
 | title = Symbol Processing and Connectionist Models in Artificial Intelligence and Cognition: Steps Toward Integration
 | year = 1993}}.
*{{citation
 | last = Gibbons | first = Jeremy | authorlink = Jeremy Gibbons
 | doi = 10.1007/3-540-46000-4\_18
 | editor1-last = Arbab | editor1-first = Farhad
 | editor2-last = Talcott | editor2-first = Carolyn
 | pages = 339–350
 | publisher = Springer-Verlag
 | series = Lecture Notes in Computer Science
 | title = Proc. 5th International Conference on Coordination Models and Languages
 | url = http://www.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/superposition-extended.pdf
 | volume = 2315
 | year = 2002}}.
*{{citation
 | last1 = Korn | first1 = Henry
 | last2 = Liberi | first2 = Albert
 | isbn = 0-07-035339-5
 | location = New York, NY
 | publisher = McGraw-Hill
 | title = An Elementary Approach to Functions
 | year = 1974}}.
*{{citation
 | last = Kracht | first = Marcus
 | contribution = Strict compositionality and literal movement grammars
 | doi = 10.1007/3-540-45738-0_8
 | pages = 126–143
 | publisher = Springer-Verlag
 | series = Lecture Notes in Computer Science
 | title = Proc. 3rd International Conference on Logical Aspects of Computational Linguistics
 | volume = 2014
 | year = 2001}}.
*{{citation
 | last = Meyer | first = Bertrand | author-link = Bertrand Meyer
 | isbn = 0-13-629049-3
 | location = New York, NY
 | pages = 13–15
 | publisher = Prentice Hall
 | title = Object-oriented Software Construction
 | year = 1988}}.
*{{citation
 | last = Miller | first = George A. | author-link = George Armitage Miller
 | journal = Psychological Review
 | pages = 81–97
 | title = The magical number seven, plus or minus two: some limits on our capacity for processing information
 | url = http://psychclassics.asu.edu/Miller/
 | volume = 63
 | year = 1956
 | doi = 10.1037/h0043158
 | pmid = 13310704
 | issue = 2}}.
*{{citation
 | last1 = Pierce | first1 = Benjamin C.
 | last2 = Turner | first2 = David N.
 | contribution = Pict: A programming language based on the pi-calculus
 | isbn = 0-262-16188-5
 | location = Cambridge, MA
 | pages = 455–494
 | publisher = MIT Press
 | series = Foundations Of Computing Series
 | title = Proof, Language, and Interaction: Essays in Honour of Robin Milner
 | url = http://www.cis.upenn.edu/~bcpierce/papers/pict-design.ps
 | year = 2000}}.
*{{citation
 | last = Raymond | first = Eric S. | author-link = Eric S. Raymond
 | contribution = 1.6.3 Rule of Composition: Design programs to be connected with other programs
 | isbn = 978-0-13-142901-7
 | pages = 15–16
 | publisher = Addison-Wesley
 | title = [[The Art of Unix Programming]]
 | url = http://catb.org/esr/writings/taoup/html/ch01s06.html#id2877684
 | year = 2003}}.
*{{citation
 | last = Steele | first = Guy L., Jr. | author-link = Guy L. Steele, Jr.
 | contribution = Building interpreters by composing monads
 | doi = 10.1145/174675.178068
 | pages = 472–492
 | title = [[Symposium on Principles of Programming Languages|Proc. 21st ACM Symposium on Principles of Programming Languages]]
 | url = http://groups.csail.mit.edu/mac/~dae/related-papers/steele.ps.Z
 | year = 1994}}.

[[Category:Programming language topics]]
[[Category:Higher-order functions]]