- functions like \hs{unsafePerformIO}, which should be prevented whenever
- possible). This means that the output of a function solely depends on
- its inputs. If you evaluate a given function with given inputs, it will
- always provide the same output.
-
- TODO: Define pure
-
- This is a perfect match for a combinatoric circuit, where the output
- also soley depend on the inputs. However, when state is involved, this
- no longer holds. Since we're in charge of our own language, we could
- remove this purity constraint and allow a function to return different
- values depending on the cycle in which it is evaluated (or rather, the
- current state). However, this means that all kinds of interesting
- properties of our functional language get lost, and all kinds of
- transformations and optimizations might no longer be meaning preserving.
-
- Provided that we want to keep the function pure, the current state has
- to be present in the function's arguments in some way. There seem to be
- two obvious ways to do this: Adding the current state as an argument, or
- including the full history of each argument.
+ functions with the \hs{IO} monad, which is not supported by Cλash). This
+ means that the output of a function solely depends on its inputs. If you
+ evaluate a given function with given inputs, it will always provide the
+ same output.
+
+ \placeintermezzo{}{
+ \defref{purity}
+ \startframedtext[width=8cm,background=box,frame=no]
+ \startalignment[center]
+ {\tfa Purity}
+ \stopalignment
+ \blank[medium]
+
+ A function is said to be pure if it satisfies two conditions:
+
+ \startitemize[KR]
+ \item When a pure function is called with the same arguments twice, it should
+ return the same value in both cases.
+ \item When a pure function is called, it should have not
+ observable side-effects.
+ \stopitemize
+
+ Purity is an important property in functional languages, since
+ it enables all kinds of mathematical reasoning and
+ optimizattions with pure functions, that are not guaranteed to
+ be correct for impure functions.
+
+ An example of a pure function is the square root function
+ \hs{sqrt}. An example of an impure function is the \hs{today}
+ function that returns the current date (which of course cannot
+ exist like this in Haskell).
+ \stopframedtext
+ }
+
+ This is a perfect match for a combinational circuit, where the output
+ also solely depends on the inputs. However, when state is involved, this
+ no longer holds. Of course this purity constraint cannot just be
+ removed from Haskell. But even when designing a completely new (hardware
+ description) language, it does not seem to be a good idea to
+ remove this purity. This would that all kinds of interesting properties of
+ the functional language get lost, and all kinds of transformations
+ and optimizations are no longer be meaning preserving.
+
+ So our functions must remain pure, meaning the current state has
+ to be present in the function's arguments in some way. There seem
+ to be two obvious ways to do this: Adding the current state as an
+ argument, or including the full history of each argument.