Monad (functional programming) - Revision history

Citation bot: Altered doi-broken-date. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox2 | #UCB_webform_linked 398/904

2025-06-04T23:45:57Z

Altered doi-broken-date. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox2 | #UCB_webform_linked 398/904

← Previous revision		Revision as of 23:45, 4 June 2025
Line 647:		Line 647:

	Using free monads intentionally may seem impractical at first, but their formal nature is particularly well-suited for syntactic problems.		Using free monads intentionally may seem impractical at first, but their formal nature is particularly well-suited for syntactic problems.
	A free monad can be used to track syntax and type while leaving semantics for later, and has found use in parsers and [[interpreter (computing)\|interpreter]]s as a result.<ref name="Swierstra2008">{{cite journal \|last=Swierstra \|first=Wouter \|year=2008 \|title=Data types à la carte \|url=https://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf \|department=Functional Pearl \|journal=Journal of Functional Programming \|publisher=Cambridge University Press \|volume=18 \|issue=4 \|pages=423–436 \|citeseerx=10.1.1.101.4131 \|doi=10.1017/s0956796808006758 \|doi-broken-date=1 ~~November~~ ~~2024~~ \|issn=1469-7653 \|s2cid=21038598}}</ref>		A free monad can be used to track syntax and type while leaving semantics for later, and has found use in parsers and [[interpreter (computing)\|interpreter]]s as a result.<ref name="Swierstra2008">{{cite journal \|last=Swierstra \|first=Wouter \|year=2008 \|title=Data types à la carte \|url=https://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf \|department=Functional Pearl \|journal=Journal of Functional Programming \|publisher=Cambridge University Press \|volume=18 \|issue=4 \|pages=423–436 \|citeseerx=10.1.1.101.4131 \|doi=10.1017/s0956796808006758 \|doi-broken-date=4 June 2025 \|issn=1469-7653 \|s2cid=21038598}}</ref>
	Others have applied them to more dynamic, operational problems too, such as providing [[iteratee]]s within a language.<ref name="Kiselyov2012">{{cite conference \|last=Kiselyov \|first=Oleg \|date=May 2012 \|editor1-last=Schrijvers \|editor1-first=Tom \|editor2-last=Thiemann \|editor2-first=Peter \|title=Iteratees \|url=http://okmij.org/ftp/Haskell/Iteratee/describe.pdf \|conference=International Symposium on Functional and Logic Programming \|series=Lecture Notes in Computer Science \|location=Kobe, Japan \|publisher=Springer-Verlag \|volume=7294 \|pages=166–181 \|doi=10.1007/978-3-642-29822-6_15 \|isbn=978-3-642-29822-6}}</ref>		Others have applied them to more dynamic, operational problems too, such as providing [[iteratee]]s within a language.<ref name="Kiselyov2012">{{cite conference \|last=Kiselyov \|first=Oleg \|date=May 2012 \|editor1-last=Schrijvers \|editor1-first=Tom \|editor2-last=Thiemann \|editor2-first=Peter \|title=Iteratees \|url=http://okmij.org/ftp/Haskell/Iteratee/describe.pdf \|conference=International Symposium on Functional and Logic Programming \|series=Lecture Notes in Computer Science \|location=Kobe, Japan \|publisher=Springer-Verlag \|volume=7294 \|pages=166–181 \|doi=10.1007/978-3-642-29822-6_15 \|isbn=978-3-642-29822-6}}</ref>

OAbot: Open access bot: url-access updated in citation with #oabot.

2025-05-24T15:46:25Z

Open access bot: url-access updated in citation with #oabot.

← Previous revision		Revision as of 15:46, 24 May 2025
Line 159:		Line 159:

	==History==		==History==
	The term "monad" in programming dates to the [[APL (programming language)\|APL]] and [[J (programming language)\|J]] programming languages, which do tend toward being purely functional. However, in those languages, "monad" is only shorthand for a function taking one parameter (a function with two parameters being a "dyad", and so on).<ref name="APL">{{cite journal \| author-link = Kenneth E. Iverson \| last = Iverson \| first = Kenneth \| date = September 1987 \| title = A dictionary of APL \| url = http://www.jsoftware.com/papers/APLDictionary.htm \| journal = APL Quote Quad \| volume = 18 \| issue = 1 \| pages = 5–40 \| doi = 10.1145/36983.36984 \| s2cid = 18301178 \| issn = 1088-6826 \| access-date = 19 November 2018}}</ref>		The term "monad" in programming dates to the [[APL (programming language)\|APL]] and [[J (programming language)\|J]] programming languages, which do tend toward being purely functional. However, in those languages, "monad" is only shorthand for a function taking one parameter (a function with two parameters being a "dyad", and so on).<ref name="APL">{{cite journal \| author-link = Kenneth E. Iverson \| last = Iverson \| first = Kenneth \| date = September 1987 \| title = A dictionary of APL \| url = http://www.jsoftware.com/papers/APLDictionary.htm \| journal = APL Quote Quad \| volume = 18 \| issue = 1 \| pages = 5–40 \| doi = 10.1145/36983.36984 \| s2cid = 18301178 \| issn = 1088-6826 \| access-date = 19 November 2018\| url-access = subscription }}</ref>

	The mathematician [[Roger Godement]] was the first to formulate the concept of a monad (dubbing it a "standard construction") in the late 1950s, though the term "monad" that came to dominate was popularized by category-theorist [[Saunders Mac Lane]].{{Citation needed\|reason=Don't have a copy of Mac Lane's book right now, but that could probably work as a source here\|date=October 2018}} The form defined above using {{mvar\|bind}}, however, was originally described in 1965 by mathematician [[Heinrich Kleisli]] in order to prove that any monad could be characterized as an [[adjunction (category theory)\|adjunction]] between two (covariant) functors.<ref name="Kleisli1965">{{cite journal \| author-link = Heinrich Kleisli \| last = Kleisli \| first = Heinrich \| date = 1965 \| title = Every standard construction is induced by a pair of adjoint functors \| url = https://www.ams.org/journals/proc/1965-016-03/S0002-9939-1965-0177024-4/S0002-9939-1965-0177024-4.pdf \| journal = Proceedings of the American Mathematical Society \| volume = 16 \| issue = 3 \| pages = 544–546 \| doi = 10.1090/S0002-9939-1965-0177024-4 \| access-date = 19 November 2018\| doi-access = free }}</ref>		The mathematician [[Roger Godement]] was the first to formulate the concept of a monad (dubbing it a "standard construction") in the late 1950s, though the term "monad" that came to dominate was popularized by category-theorist [[Saunders Mac Lane]].{{Citation needed\|reason=Don't have a copy of Mac Lane's book right now, but that could probably work as a source here\|date=October 2018}} The form defined above using {{mvar\|bind}}, however, was originally described in 1965 by mathematician [[Heinrich Kleisli]] in order to prove that any monad could be characterized as an [[adjunction (category theory)\|adjunction]] between two (covariant) functors.<ref name="Kleisli1965">{{cite journal \| author-link = Heinrich Kleisli \| last = Kleisli \| first = Heinrich \| date = 1965 \| title = Every standard construction is induced by a pair of adjoint functors \| url = https://www.ams.org/journals/proc/1965-016-03/S0002-9939-1965-0177024-4/S0002-9939-1965-0177024-4.pdf \| journal = Proceedings of the American Mathematical Society \| volume = 16 \| issue = 3 \| pages = 544–546 \| doi = 10.1090/S0002-9939-1965-0177024-4 \| access-date = 19 November 2018\| doi-access = free }}</ref>

Leastfixedpoint: /* IO monad (Haskell) */ Removed nonsensical invocation of the concept of referential transparency.

2025-05-11T18:10:35Z

IO monad (Haskell): Removed nonsensical invocation of the concept of referential transparency.

← Previous revision		Revision as of 18:10, 11 May 2025
Line 393:		Line 393:
	As already mentioned, pure code should not have unmanaged side effects, but that does not preclude a program from ''explicitly'' describing and managing effects.		As already mentioned, pure code should not have unmanaged side effects, but that does not preclude a program from ''explicitly'' describing and managing effects.
	This idea is central to Haskell's '''IO monad''', where an object of type <code>IO a</code> can be seen as describing an action to be performed in the world, optionally providing information about the world of type <code>a</code>. An action that provides no information about the world has the type <code>IO ()</code>, "providing" the dummy value <code>()</code>.		This idea is central to Haskell's '''IO monad''', where an object of type <code>IO a</code> can be seen as describing an action to be performed in the world, optionally providing information about the world of type <code>a</code>. An action that provides no information about the world has the type <code>IO ()</code>, "providing" the dummy value <code>()</code>.
	When a programmer binds an <code>IO</code> value to a function, the function computes the next action to be performed based on the information about the world provided by the previous action (input from users, files, etc.).<ref name="PeytonWadler1993">{{cite conference \| author-link1 = Simon Peyton Jones \| author-link2 = Philip Wadler \| last1 = Peyton Jones \| first1 = Simon L. \| last2 = Wadler \| first2 = Philip \| title = Imperative functional programming \| date = January 1993 \| conference = 20th Annual ACM Symposium on Principles of Programming Languages \| location = Charleston, South Carolina \| url = https://www.microsoft.com/en-us/research/wp-content/uploads/1993/01/imperative.pdf \| citeseerx = 10.1.1.53.2504}}</ref> Most significantly, because the value of the IO monad can only be bound to a function that computes another IO monad, the bind function imposes a discipline of a sequence of actions where the result of an action can only be provided to a function that will compute the next action to perform. This means that actions which do not need to be performed never are, and actions that do need to be performed have a well defined sequence~~, solving the problem of (IO) actions not being [[referentially transparent]]~~.		When a programmer binds an <code>IO</code> value to a function, the function computes the next action to be performed based on the information about the world provided by the previous action (input from users, files, etc.).<ref name="PeytonWadler1993">{{cite conference \| author-link1 = Simon Peyton Jones \| author-link2 = Philip Wadler \| last1 = Peyton Jones \| first1 = Simon L. \| last2 = Wadler \| first2 = Philip \| title = Imperative functional programming \| date = January 1993 \| conference = 20th Annual ACM Symposium on Principles of Programming Languages \| location = Charleston, South Carolina \| url = https://www.microsoft.com/en-us/research/wp-content/uploads/1993/01/imperative.pdf \| citeseerx = 10.1.1.53.2504}}</ref> Most significantly, because the value of the IO monad can only be bound to a function that computes another IO monad, the bind function imposes a discipline of a sequence of actions where the result of an action can only be provided to a function that will compute the next action to perform. This means that actions which do not need to be performed never are, and actions that do need to be performed have a well defined sequence.

	For example, Haskell has several functions for acting on the wider [[file system]], including one that checks whether a file exists and another that deletes a file.		For example, Haskell has several functions for acting on the wider [[file system]], including one that checks whether a file exists and another that deletes a file.

2604:3D08:6380:EF00:987E:5A77:86CE:348: Updated the "Empty" Rust option from "Nothing" (which doesn't exist) to "None", which is proper Rust syntax.

2025-03-30T21:33:16Z

Updated the "Empty" Rust option from "Nothing" (which doesn't exist) to "None", which is proper Rust syntax.

← Previous revision		Revision as of 21:33, 30 March 2025
Line 36:		Line 36:
	enum Option<T> {		enum Option<T> {
	Some(T),		Some(T),
	~~Nothing~~,		None,
	}		}
	</syntaxhighlight>		</syntaxhighlight>

IANSYT: In the Rust it... --> In the Rust programming language it

2025-03-27T19:07:22Z

In the Rust it... --> In the Rust programming language it

← Previous revision		Revision as of 19:07, 27 March 2025
Line 30:		Line 30:
	One example of a monad is the <code>Maybe</code> type. Undefined null results are one particular pain point that many procedural languages don't provide specific tools for dealing with, requiring use of the [[null object pattern]] or checks to test for invalid values at each operation to handle undefined values. This causes bugs and makes it harder to build robust software that gracefully handles errors. The <code>Maybe</code> type forces the programmer to deal with these potentially undefined results by explicitly defining the two states of a result: <code>Just ⌑result⌑</code>, or <code>Nothing</code>. For example the programmer might be constructing a parser, which is to return an intermediate result, or else signal a condition which the parser has detected, and which the programmer must also handle. With just a little extra functional spice on top, this <code>Maybe</code> type transforms into a fully-featured monad.{{efn\|name= gHutton2ndMaybe\|Specific motivation for Maybe can be found in (Hutton 2016).<ref name=gHutton2016 >Graham Hutton (2016) ''Programming in Haskell'' 2nd Edition</ref>}}{{rp\|12.3 pages 148–151}}		One example of a monad is the <code>Maybe</code> type. Undefined null results are one particular pain point that many procedural languages don't provide specific tools for dealing with, requiring use of the [[null object pattern]] or checks to test for invalid values at each operation to handle undefined values. This causes bugs and makes it harder to build robust software that gracefully handles errors. The <code>Maybe</code> type forces the programmer to deal with these potentially undefined results by explicitly defining the two states of a result: <code>Just ⌑result⌑</code>, or <code>Nothing</code>. For example the programmer might be constructing a parser, which is to return an intermediate result, or else signal a condition which the parser has detected, and which the programmer must also handle. With just a little extra functional spice on top, this <code>Maybe</code> type transforms into a fully-featured monad.{{efn\|name= gHutton2ndMaybe\|Specific motivation for Maybe can be found in (Hutton 2016).<ref name=gHutton2016 >Graham Hutton (2016) ''Programming in Haskell'' 2nd Edition</ref>}}{{rp\|12.3 pages 148–151}}

	In most languages, the Maybe monad is also known as an [[option type]], which is just a type that marks whether or not it contains a value. Typically they are expressed as some kind of [[enumerated type]]. In the [[Rust (programming language)\|Rust]] it is called <code>Option<T></code> and variants of this type can either be a value of [[generic type]] <code>T</code>, or the empty variant: <code>None</code>.		In most languages, the Maybe monad is also known as an [[option type]], which is just a type that marks whether or not it contains a value. Typically they are expressed as some kind of [[enumerated type]]. In the [[Rust (programming language)\|Rust]] programming language it is called <code>Option<T></code> and variants of this type can either be a value of [[generic type]] <code>T</code>, or the empty variant: <code>None</code>.

	<syntaxhighlight lang="rust">		<syntaxhighlight lang="rust">

Steveklabnik: Change Rust examples to use the action name Rust uses.

2025-03-27T15:24:08Z

Change Rust examples to use the action name Rust uses.

← Previous revision		Revision as of 15:24, 27 March 2025
Line 30:		Line 30:
	One example of a monad is the <code>Maybe</code> type. Undefined null results are one particular pain point that many procedural languages don't provide specific tools for dealing with, requiring use of the [[null object pattern]] or checks to test for invalid values at each operation to handle undefined values. This causes bugs and makes it harder to build robust software that gracefully handles errors. The <code>Maybe</code> type forces the programmer to deal with these potentially undefined results by explicitly defining the two states of a result: <code>Just ⌑result⌑</code>, or <code>Nothing</code>. For example the programmer might be constructing a parser, which is to return an intermediate result, or else signal a condition which the parser has detected, and which the programmer must also handle. With just a little extra functional spice on top, this <code>Maybe</code> type transforms into a fully-featured monad.{{efn\|name= gHutton2ndMaybe\|Specific motivation for Maybe can be found in (Hutton 2016).<ref name=gHutton2016 >Graham Hutton (2016) ''Programming in Haskell'' 2nd Edition</ref>}}{{rp\|12.3 pages 148–151}}		One example of a monad is the <code>Maybe</code> type. Undefined null results are one particular pain point that many procedural languages don't provide specific tools for dealing with, requiring use of the [[null object pattern]] or checks to test for invalid values at each operation to handle undefined values. This causes bugs and makes it harder to build robust software that gracefully handles errors. The <code>Maybe</code> type forces the programmer to deal with these potentially undefined results by explicitly defining the two states of a result: <code>Just ⌑result⌑</code>, or <code>Nothing</code>. For example the programmer might be constructing a parser, which is to return an intermediate result, or else signal a condition which the parser has detected, and which the programmer must also handle. With just a little extra functional spice on top, this <code>Maybe</code> type transforms into a fully-featured monad.{{efn\|name= gHutton2ndMaybe\|Specific motivation for Maybe can be found in (Hutton 2016).<ref name=gHutton2016 >Graham Hutton (2016) ''Programming in Haskell'' 2nd Edition</ref>}}{{rp\|12.3 pages 148–151}}

	In most languages, the Maybe monad is also known as an [[option type]], which is just a type that marks whether or not it contains a value. Typically they are expressed as some kind of [[enumerated type]]. In ~~this~~ [[Rust (programming language)\|Rust]] ~~example~~ we ~~will call it~~ <code>~~Maybe~~<T></code> and variants of this type can either be a value of [[generic type]] <code>T</code>, or the empty variant: <code>~~Nothing~~</code>.		In most languages, the Maybe monad is also known as an [[option type]], which is just a type that marks whether or not it contains a value. Typically they are expressed as some kind of [[enumerated type]]. In the [[Rust (programming language)\|Rust]] it is called <code>Option<T></code> and variants of this type can either be a value of [[generic type]] <code>T</code>, or the empty variant: <code>None</code>.

	<syntaxhighlight lang="rust">		<syntaxhighlight lang="rust">
	// The <T> represents a generic type "T"		// The <T> represents a generic type "T"
	enum ~~Maybe~~<T> {		enum Option<T> {
	~~Just~~(T),		Some(T),
	Nothing,		Nothing,
	}		}
	</syntaxhighlight>		</syntaxhighlight>

	<code>~~Maybe~~<T></code> can also be understood as a "wrapping" type, and this is where its connection to monads comes in. In languages with some form of the ~~<code>~~Maybe~~</code>~~ type, there are functions that aid in their use such as composing '''monadic functions''' with each other and testing if a ~~<code>~~Maybe~~</code>~~ contains a value.		<code>Option<T></code> can also be understood as a "wrapping" type, and this is where its connection to monads comes in. In languages with some form of the Maybe type, there are functions that aid in their use such as composing '''monadic functions''' with each other and testing if a Maybe contains a value.

	In the following hard-coded example, a ~~<code>~~Maybe~~</code>~~ type is used as a result of functions that may fail, in this case the type returns nothing if there is a [[divide-by-zero]].<syntaxhighlight lang="rust">		In the following hard-coded example, a Maybe type is used as a result of functions that may fail, in this case the type returns nothing if there is a [[divide-by-zero]].<syntaxhighlight lang="rust">
	fn divide(x: Decimal, y: Decimal) -> ~~Maybe~~<Decimal> {		fn divide(x: Decimal, y: Decimal) -> Option<Decimal> {
	if y == 0 { return ~~Nothing~~ }		if y == 0 { return None }
	else { return ~~Just~~(x / y) }		else { return Some(x / y) }
	}		}
	// divide(1.0, 4.0) -> returns ~~Just~~(0.25)		// divide(1.0, 4.0) -> returns Some(0.25)
	// divide(3.0, 0.0) -> returns ~~Nothing~~		// divide(3.0, 0.0) -> returns None
	</syntaxhighlight>One such way to test whether or not a ~~<code>~~Maybe~~</code>~~ contains a value is to use <code>if</code> statements.<syntaxhighlight lang="rust">		</syntaxhighlight>One such way to test whether or not a Maybe contains a value is to use <code>if</code> statements.<syntaxhighlight lang="rust">
	let m_x = divide(3.14, 0.0); // see divide function above		let m_x = divide(3.14, 0.0); // see divide function above
	// The if statement extracts x from m_x if m_x is the Just variant of Maybe		// The if statement extracts x from m_x if m_x is the Just variant of Maybe
	if let ~~Just~~(x) = m_x {		if let Some(x) = m_x {
	println!("answer: ", x)		println!("answer: ", x)
	} else {		} else {
Line 60:		Line 60:
	let result = divide(3.0, 2.0);		let result = divide(3.0, 2.0);
	match result {		match result {
	~~Just~~(x) => println!("Answer: ", x),		Some(x) => println!("Answer: ", x),
	~~Nothing~~ => println!("division failed; we'll get 'em next time."),		None => println!("division failed; we'll get 'em next time."),
	}		}
	</syntaxhighlight>Monads can compose functions that return ~~<code>~~Maybe~~</code>~~, putting them together. A concrete example might have one function take in several ~~<code>~~Maybe~~</code>~~ parameters, and return a single ~~<code>~~Maybe~~</code>~~ whose value is ~~<code>~~Nothing~~</code>~~ when any of the parameters are ~~<code>~~Nothing~~</code>~~, as in the following:		</syntaxhighlight>Monads can compose functions that return Maybe, putting them together. A concrete example might have one function take in several Maybe parameters, and return a single Maybe whose value is Nothing when any of the parameters are Nothing, as in the following:

	<syntaxhighlight lang="rust">		<syntaxhighlight lang="rust">
	fn chainable_division(maybe_x: ~~Maybe~~<Decimal>, maybe_y: ~~Maybe~~<Decimal>) -> ~~Maybe~~<Decimal> {		fn chainable_division(maybe_x: Option<Decimal>, maybe_y: Option<Decimal>) -> Option<Decimal> {
	match (maybe_x, maybe_y) {		match (maybe_x, maybe_y) {
	(~~Just~~(x), ~~Just~~(y)) => { // If both inputs are ~~Just~~, check for division by zero and divide accordingly		(Some(x), Some(y)) => { // If both inputs are Some, check for division by zero and divide accordingly
	if y == 0 { return ~~Nothing~~ }		if y == 0 { return None }
	else { return ~~Just~~(x / y) }		else { return Some(x / y) }
	},		},
	_ => return ~~Nothing~~ // Otherwise return ~~Nothing~~		_ => return None // Otherwise return None
	}		}
	}		}
	chainable_division(chainable_division(~~Just~~(2.0), ~~Just~~(0.0)), ~~Just~~(1.0)); // inside chainable_division fails, outside chainable_division returns ~~Nothing~~		chainable_division(chainable_division(Some(2.0), Some(0.0)), Some(1.0)); // inside chainable_division fails, outside chainable_division returns None
	</syntaxhighlight>		</syntaxhighlight>

	Instead of repeating <code>~~Just~~</code> expressions, we can use something called a ''bind'' operator. (also known as "map", "flatmap", or "shove"<ref name= Beckerman>{{Cite web\|last=Beckerman\|first=Brian\|date=21 November 2012\|title=Don't fear the Monad\|website=[[YouTube]]\|url=https://www.youtube.com/watch?v=ZhuHCtR3xq8&t=2205s}}</ref>{{rp\|2205s}}). This operation takes a monad and a function that returns a monad and runs the function on the inner value of the passed monad, returning the monad from the function.<syntaxhighlight lang="rust">		Instead of repeating <code>Some</code> expressions, we can use something called a ''bind'' operator. (also known as "map", "flatmap", or "shove"<ref name= Beckerman>{{Cite web\|last=Beckerman\|first=Brian\|date=21 November 2012\|title=Don't fear the Monad\|website=[[YouTube]]\|url=https://www.youtube.com/watch?v=ZhuHCtR3xq8&t=2205s}}</ref>{{rp\|2205s}}). This operation takes a monad and a function that returns a monad and runs the function on the inner value of the passed monad, returning the monad from the function.<syntaxhighlight lang="rust">
	// Rust example using ".map". maybe_x is passed through 2 functions that return ~~Maybe~~<Decimal> and ~~Maybe~~<String> respectively.		// Rust example using ".map". maybe_x is passed through 2 functions that return Some<Decimal> and Some<String> respectively.
	// As with normal function composition the inputs and outputs of functions feeding into each other should match wrapped types. (i.e. the add_one function should return a ~~Maybe~~<Decimal> which then can be unwrapped to a Decimal for the decimal_to_string function)		// As with normal function composition the inputs and outputs of functions feeding into each other should match wrapped types. (i.e. the add_one function should return a Some<Decimal> which then can be unwrapped to a Decimal for the decimal_to_string function)
	let maybe_x: ~~Maybe~~<Decimal> = ~~Just~~(1.0)		let maybe_x: Some<Decimal> = Option(1.0)
	let maybe_result = maybe_x.map(add_one).map(decimal_to_string)		let maybe_result = maybe_x.map(add_one).map(decimal_to_string)
	</syntaxhighlight>In Haskell, there is an operator ''bind'', or (<code>>>=</code>) that allows for this monadic composition in a more elegant form similar to [[function composition]].{{efn\|name= gHutton2ndBind\|Hutton abstracts a <code>bind</code> which when given a type ''a'' that may fail, and a mapping ''a''→''b'' that may fail, produces a result ''b'' that may fail. (Hutton, 2016)<ref name=gHutton2016/> }}{{rp\|150–151}}		</syntaxhighlight>In Haskell, there is an operator ''bind'', or (<code>>>=</code>) that allows for this monadic composition in a more elegant form similar to [[function composition]].{{efn\|name= gHutton2ndBind\|Hutton abstracts a <code>bind</code> which when given a type ''a'' that may fail, and a mapping ''a''→''b'' that may fail, produces a result ''b'' that may fail. (Hutton, 2016)<ref name=gHutton2016/> }}{{rp\|150–151}}

2003:CE:8707:4D62:F57D:3626:4A5A:47FF: a → an

2025-01-29T13:42:53Z

a → an

← Previous revision		Revision as of 13:42, 29 January 2025
Line 4:		Line 4:
	In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side effect. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>		In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side effect. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>

	Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>		Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as an [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>

	Since monads make [[semantics (computer science)\|semantics]] explicit for a kind of computation, they can also be used to implement convenient language features. Some languages, such as [[Haskell (programming language)\|Haskell]], even offer pre-built definitions in their core [[library (computing)\|libraries]] for the general monad structure and common instances.<ref name="RealWorldHaskell" /><ref name="GentleIntroHaskell">{{cite book \| author-link1 = Paul Hudak \| last1 = Hudak \| first1 = Paul \| last2 = Peterson \| first2 = John \| last3 = Fasel \| first3 = Joseph \| title = A Gentle Introduction to Haskell 98 \| year = 1999 \| chapter = About Monads \| at = chapter 9 \| chapter-url = https://www.haskell.org/tutorial/monads.html \| url = https://www.haskell.org/tutorial/index.html}}</ref>		Since monads make [[semantics (computer science)\|semantics]] explicit for a kind of computation, they can also be used to implement convenient language features. Some languages, such as [[Haskell (programming language)\|Haskell]], even offer pre-built definitions in their core [[library (computing)\|libraries]] for the general monad structure and common instances.<ref name="RealWorldHaskell" /><ref name="GentleIntroHaskell">{{cite book \| author-link1 = Paul Hudak \| last1 = Hudak \| first1 = Paul \| last2 = Peterson \| first2 = John \| last3 = Fasel \| first3 = Joseph \| title = A Gentle Introduction to Haskell 98 \| year = 1999 \| chapter = About Monads \| at = chapter 9 \| chapter-url = https://www.haskell.org/tutorial/monads.html \| url = https://www.haskell.org/tutorial/index.html}}</ref>

Zontasticality: Undid revision 1271995853 by Remsense (talk)

2025-01-27T23:09:09Z

Undid revision 1271995853 by Remsense (talk)

← Previous revision		Revision as of 23:09, 27 January 2025
Line 2:		Line 2:
	{{for\|the concept in category theory\|Monad (category theory)}}		{{for\|the concept in category theory\|Monad (category theory)}}

	In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side ~~effects~~. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>		In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side effect. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>

	Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>		Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>

Remsense: Undid revision 1271993670 by 128.119.202.170 (talk): correct before

2025-01-26T18:01:56Z

Undid revision 1271993670 by 128.119.202.170 (talk): correct before

← Previous revision		Revision as of 18:01, 26 January 2025
Line 2:		Line 2:
	{{for\|the concept in category theory\|Monad (category theory)}}		{{for\|the concept in category theory\|Monad (category theory)}}

	In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side ~~effect~~. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>		In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side effects. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>

	Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>		Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>

128.119.202.170: removed s

2025-01-26T17:49:53Z

removed s

← Previous revision		Revision as of 17:49, 26 January 2025
Line 2:		Line 2:
	{{for\|the concept in category theory\|Monad (category theory)}}		{{for\|the concept in category theory\|Monad (category theory)}}

	In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side ~~effects~~. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>		In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side effect. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>

	Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>		Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>

← Previous revision		Revision as of 13:42, 29 January 2025
Line 4:		Line 4:
	In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side effect. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>		In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side effect. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>

	Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>		Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as an [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>

	Since monads make [[semantics (computer science)\|semantics]] explicit for a kind of computation, they can also be used to implement convenient language features. Some languages, such as [[Haskell (programming language)\|Haskell]], even offer pre-built definitions in their core [[library (computing)\|libraries]] for the general monad structure and common instances.<ref name="RealWorldHaskell" /><ref name="GentleIntroHaskell">{{cite book \| author-link1 = Paul Hudak \| last1 = Hudak \| first1 = Paul \| last2 = Peterson \| first2 = John \| last3 = Fasel \| first3 = Joseph \| title = A Gentle Introduction to Haskell 98 \| year = 1999 \| chapter = About Monads \| at = chapter 9 \| chapter-url = https://www.haskell.org/tutorial/monads.html \| url = https://www.haskell.org/tutorial/index.html}}</ref>		Since monads make [[semantics (computer science)\|semantics]] explicit for a kind of computation, they can also be used to implement convenient language features. Some languages, such as [[Haskell (programming language)\|Haskell]], even offer pre-built definitions in their core [[library (computing)\|libraries]] for the general monad structure and common instances.<ref name="RealWorldHaskell" /><ref name="GentleIntroHaskell">{{cite book \| author-link1 = Paul Hudak \| last1 = Hudak \| first1 = Paul \| last2 = Peterson \| first2 = John \| last3 = Fasel \| first3 = Joseph \| title = A Gentle Introduction to Haskell 98 \| year = 1999 \| chapter = About Monads \| at = chapter 9 \| chapter-url = https://www.haskell.org/tutorial/monads.html \| url = https://www.haskell.org/tutorial/index.html}}</ref>

← Previous revision		Revision as of 23:09, 27 January 2025
Line 2:		Line 2:
	{{for\|the concept in category theory\|Monad (category theory)}}		{{for\|the concept in category theory\|Monad (category theory)}}

	In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side ~~effects~~. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>		In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side effect. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>

	Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>		Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>

← Previous revision		Revision as of 18:01, 26 January 2025
Line 2:		Line 2:
	{{for\|the concept in category theory\|Monad (category theory)}}		{{for\|the concept in category theory\|Monad (category theory)}}

	In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side ~~effect~~. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>		In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side effects. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>

	Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>		Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>

← Previous revision		Revision as of 17:49, 26 January 2025
Line 2:		Line 2:
	{{for\|the concept in category theory\|Monad (category theory)}}		{{for\|the concept in category theory\|Monad (category theory)}}

	In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side ~~effects~~. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>		In [[functional programming]], '''monads''' are a way to structure computations as a sequence of steps, where each step not only produces a value but also some extra information about the computation, such as a potential failure, non-determinism, or side effect. More formally, a monad is a [[type constructor]] M equipped with two operations, {{Code\|return : <A>(a : A) -> M(A)\|typescript}} which lifts a value into the monadic context, and {{Code\|bind : <A,B>(m_a : M(A), f : A -> M(B)) -> M(B)\|typescript}} which chains monadic computations. In simpler terms, monads can be thought of as [[Interface (computing)\|interfaces]] implemented on type constructors, that allow for functions to abstract over various type constructor variants that implement monad (e.g. {{Code\|Option}}, {{Code\|List}}, etc.).<ref name="RealWorldHaskell">{{cite book\|last1=O'Sullivan\|first1=Bryan\|url=http://book.realworldhaskell.org/\|title=Real World Haskell\|last2=Goerzen\|first2=John\|last3=Stewart\|first3=Don\|publisher=O'Reilly Media\|year=2009\|isbn=978-0596514983\|location=Sebastopol, California\|at=chapter 14\|chapter=Monads\|chapter-url=http://book.realworldhaskell.org/read/monads.html}}</ref><ref name="Wadler1990">{{cite conference\|last=Wadler\|first=Philip\|author-link=Philip Wadler\|date=June 1990\|title=Comprehending Monads\|conference=ACM Conference on LISP and Functional Programming\|location=Nice, France\|citeseerx=10.1.1.33.5381}}</ref>

	Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>		Both the concept of a monad and the term originally come from [[category theory]], where a monad is defined as a [[endofunctor]] with additional structure.{{efn\|More formally, a monad is a [[monoid (category theory)\|monoid]] in the category of [[endofunctor]]s.}}{{efn\|Due to the fact that functions on multiple [[free variable]]s are common in programming, monads as described in this article are technically what category theorists would call [[strong monad]]s.<ref name="Moggi1991" />}} Research beginning in the late 1980s and early 1990s established that monads could bring seemingly disparate computer-science problems under a unified, functional model. Category theory also provides a few formal requirements, known as the '''[[#Definition\|monad laws]]''', which should be satisfied by any monad and can be used to [[formal verification\|verify]] monadic code.<ref name="Moggi1991">{{cite journal \| author-link = Eugenio Moggi \| last = Moggi \| first = Eugenio \| year = 1991 \| title = Notions of computation and monads \| journal = Information and Computation \| volume = 93 \| issue = 1 \| pages = 55–92 \| url = http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf \| citeseerx = 10.1.1.158.5275 \| doi=10.1016/0890-5401(91)90052-4}}</ref><ref name="Wadler1992">{{cite conference \| author-link = Philip Wadler \| last = Wadler \| first = Philip \| title = The essence of functional programming \| conference = 19th Annual ACM Symposium on Principles of Programming Languages \| location = Albuquerque, New Mexico \| date = January 1992 \| citeseerx = 10.1.1.38.9516}}</ref>