Functional Reactive Programming - Revision history

Atravers at 06:32, 16 June 2025

2025-06-16T06:32:34Z

← Older revision		Revision as of 06:32, 16 June 2025
Line 121:		Line 121:
	* [https://wolfgang.jeltsch.info/publications-and-talks Grapefruit-related publications and talks]		* [https://wolfgang.jeltsch.info/publications-and-talks Grapefruit-related publications and talks]
	* [https://web.archive.org/web/20171012164802/http://haskell.cs.yale.edu/publications/#FunctionalReactiveProgramming The Yale Haskell Group’s FRP-related publications] (archived)		* [https://web.archive.org/web/20171012164802/http://haskell.cs.yale.edu/publications/#FunctionalReactiveProgramming The Yale Haskell Group’s FRP-related publications] (archived)
	* [https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.11.6997&rep=rep1&type=pdf FROB: A Transformational Approach to the Design of Robot Software - Gregory D. Hager and John Peterson]		* [https://web.archive.org/web/20220827215255/https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.11.6997&rep=rep1&type=pdf FROB: A Transformational Approach to the Design of Robot Software - Gregory D. Hager and John Peterson]
	* [https://begriffs.com/posts/2015-07-22-essence-of-frp.html The Essence of FRP (Conal Elliott -- July 22, 2015 -- video)]		* [https://begriffs.com/posts/2015-07-22-essence-of-frp.html The Essence of FRP (Conal Elliott -- July 22, 2015 -- video)]
	* [https://begriffs.com/posts/2016-07-27-tikhon-on-frp.html A Sensible Intro to FRP (Tikhon Jelvis -- July 27, 2016 -- video)]		* [https://begriffs.com/posts/2016-07-27-tikhon-on-frp.html A Sensible Intro to FRP (Tikhon Jelvis -- July 27, 2016 -- video)]

Atravers at 17:14, 18 February 2025

2025-02-18T17:14:04Z

← Older revision		Revision as of 17:14, 18 February 2025
Line 6:		Line 6:
	The original formulation of Functional Reactive Programming can be found in the ICFP 97 paper [http://conal.net/papers/icfp97/ Functional Reactive Animation] by Conal Elliott and Paul Hudak. It introduces the following ''semantic functions'':		The original formulation of Functional Reactive Programming can be found in the ICFP 97 paper [http://conal.net/papers/icfp97/ Functional Reactive Animation] by Conal Elliott and Paul Hudak. It introduces the following ''semantic functions'':

	* <b>at~~</b>~~ : ~~<i>~~Behavior~~<sub>α</sub> →~~ Time ~~→ α~~</i>		* <math>\textbf{at}\ :\ \texttt{Behavior}_\alpha \to \texttt{Time} \to \alpha</math>

	* <b>occ~~</b>~~ : ~~<i>~~Event~~<sub>α</sub> →~~ Time ~~× α~~</i>		* <math>\textbf{occ}\ :\ \texttt{Event}_\alpha \to \texttt{Time} \times \alpha</math>

	to provide a formal description of operations on values now commonly known as ''behaviors'' and ''events''. But what are they?		to provide a formal description of operations on values now commonly known as ''behaviors'' and ''events''. But what are they?
Line 69:		Line 69:

	<blockquote>		<blockquote>
	Suppose that we want to compute a function <i>F</i> on several arguments <~~i>A</i><sub>0</sub~~>, ~~<i>A</i><sub>1</sub>~~, ~~<i>A~~</~~i><sub~~>~~2</sub>,...~~ appearing consecutively in time [as discrete events]. One can view this so-called <i>stream</i> (<~~i>A</i><sub>0</sub~~>, ~~<i>A</i><sub>1</sub>~~, ~~<i>A</i><sub>2~~</~~sub~~>~~,...)~~ as a potentially infinite list <i>A~~</i>~~ = (~~<i>A</i><sub>0</sub>~~:~~<i>A</i><sub>1</sub>~~:~~<i>A</i><sub>2</sub>~~:~~···~~:~~<i>A~~</i><~~sub~~>n</~~sub~~>~~:⊥) where ⊥~~ stands for “unspecified” and is interactively updated to <~~i>A</i><sub~~>n+1</~~sub~~>:⊥ each time the user has a new argument <~~i>A</i><sub~~>n+1</~~sub~~>. Then on this list <i>A</i>, the system applies the function <i>F~~</i><sup>~~*</~~sup~~> defined by		Suppose that we want to compute a function <math>F</math> on several arguments
	::<i>F~~</i><sup>~~~~</sup>~~ (~~<i>~~A~~</i>~~:~~<i>~~B~~</i>~~) = (~~<i>~~F~~</i> <i>~~A~~</i>~~):(~~<i>~~F~~</i><sup>~~~~</sup> <i>~~B</i>)		<math>A_0,A_1,A_2,\ldots</math> appearing consecutively in time [as discrete events]. One can view this so-called <i>stream</i>
			<math>(A_0,A_1,A_2,\ldots)</math> as a potentially infinite list <math>A = (A_0:A_1:A_2:\cdots:A_n:\bot)</math> where <math>\bot</math> stands
			for “unspecified” and is interactively updated to <math>A_{n+1}:\bot</math> each time the user has a new
			argument <math>A_{n+1}</math>. Then on this list <math>A</math>, the system applies the function <math>F^*</math> defined by
			::<math>F^* (A:B) = (F A):(F^* B)</math>

	obtaining		obtaining
	::<i>F~~</i><sup>~~~~</sup> <i>~~A~~</i>~~ = (~~<i>~~F~~</i> <i>A</i><sub>0</sub>~~:~~<i>~~F~~</i> <i>A</i><sub>1</sub>~~:~~<i>~~F~~</i> <i>A</i><sub>2</sub>~~:~~···~~:~~<i>~~F~~</i> <i>A</i><sub>n</sub>~~:~~<i>~~F~~</i><sup>~~</~~sup~~> ⊥)		::<math>F^* A = (F A_0:F A_1:F A_2:\cdots:F A_n:F^* \bot)</math>

	also appearing consecutively in time.		also appearing consecutively in time.

Atravers at 16:02, 18 February 2025

2025-02-18T16:02:31Z

← Older revision		Revision as of 16:02, 18 February 2025
Line 68:		Line 68:
	The concept of an <i>event stream</i> (or simply <i>stream</i>), for representing a series of events, supports a basic model of interactivity:		The concept of an <i>event stream</i> (or simply <i>stream</i>), for representing a series of events, supports a basic model of interactivity:

	<~~div style="border-left:1px solid lightgray; padding: 1em" alt="~~blockquote">		<blockquote>
	Suppose that we want to compute a function <i>F</i> on several arguments <i>A</i><sub>0</sub>, <i>A</i><sub>1</sub>, <i>A</i><sub>2</sub>,... appearing consecutively in time [as discrete events]. One can view this so-called <i>stream</i> (<i>A</i><sub>0</sub>, <i>A</i><sub>1</sub>, <i>A</i><sub>2</sub>,...) as a potentially infinite list <i>A</i> = (<i>A</i><sub>0</sub>:<i>A</i><sub>1</sub>:<i>A</i><sub>2</sub>:···:<i>A</i><sub>n</sub>:⊥) where ⊥ stands for “unspecified” and is interactively updated to <i>A</i><sub>n+1</sub>:⊥ each time the user has a new argument <i>A</i><sub>n+1</sub>. Then on this list <i>A</i>, the system applies the function <i>F</i><sup>*</sup> defined by		Suppose that we want to compute a function <i>F</i> on several arguments <i>A</i><sub>0</sub>, <i>A</i><sub>1</sub>, <i>A</i><sub>2</sub>,... appearing consecutively in time [as discrete events]. One can view this so-called <i>stream</i> (<i>A</i><sub>0</sub>, <i>A</i><sub>1</sub>, <i>A</i><sub>2</sub>,...) as a potentially infinite list <i>A</i> = (<i>A</i><sub>0</sub>:<i>A</i><sub>1</sub>:<i>A</i><sub>2</sub>:···:<i>A</i><sub>n</sub>:⊥) where ⊥ stands for “unspecified” and is interactively updated to <i>A</i><sub>n+1</sub>:⊥ each time the user has a new argument <i>A</i><sub>n+1</sub>. Then on this list <i>A</i>, the system applies the function <i>F</i><sup>*</sup> defined by
	::<i>F</i><sup></sup> (<i>A</i>:<i>B</i>) = (<i>F</i> <i>A</i>):(<i>F</i><sup></sup> <i>B</i>)		::<i>F</i><sup></sup> (<i>A</i>:<i>B</i>) = (<i>F</i> <i>A</i>):(<i>F</i><sup></sup> <i>B</i>)
Line 77:		Line 77:
	also appearing consecutively in time.		also appearing consecutively in time.

	<tt>[https://repository.ubn.ru.nl/bitstream/handle/2066/17230/13246.pdf Functional Programming and Lambda Calculus], Henk Barendregt (page 325).</tt>		:<small>[https://repository.ubn.ru.nl/bitstream/handle/2066/17230/13246.pdf Functional Programming and Lambda Calculus], Henk Barendregt (page 325).</small>
	</~~div~~>		</blockquote>

	== Semantic functions? ==		== Semantic functions? ==

	From page 6 of [http://conal.net/papers/icfp97/icfp97.pdf the paper]:		From page 6 of [http://conal.net/papers/icfp97/icfp97.pdf the paper]:
	<~~div style="border-left:1px solid lightgray; padding: 1em" alt="~~blockquote">		<blockquote>
	An early implementation of Fran represented behaviors as implied in the formal semantics:		An early implementation of Fran represented behaviors as implied in the formal semantics:
	<haskell>		<haskell>
Line 89:		Line 89:
	</haskell>		</haskell>
	This representation, however, leads to a serious inefficiency [a “space-time” leak].		This representation, however, leads to a serious inefficiency [a “space-time” leak].
	</~~div~~>		</blockquote>

	So instead of one canonical implementation of FRP, this tendency to "leak" has led to a variety of implementations, each with its own benefit-cost trade-offs.		So instead of one canonical implementation of FRP, this tendency to "leak" has led to a variety of implementations, each with its own benefit-cost trade-offs.
Line 156:		Line 156:
	In his thesis [https://core.ac.uk/download/9835633.pdf Functional Real-Time Programming: The Language Ruth And Its Semantics], some parts of the semantics Dave Harrison gives for ''Ruth'' bears a curious resemblance to those for FRP:		In his thesis [https://core.ac.uk/download/9835633.pdf Functional Real-Time Programming: The Language Ruth And Its Semantics], some parts of the semantics Dave Harrison gives for ''Ruth'' bears a curious resemblance to those for FRP:

	* <small>(page 48)</small>		* <small>(page 48 of 221)</small>
	:{\|		:{\|
	\|<~~div style="border-left:1px solid lightgray; padding: 1em" alt="~~blockquote">		\|<blockquote>
	A channel is an infinite stream of timestamped data values, or messages, each message denoting an event in the system. [...]		A channel is an infinite stream of timestamped data values, or messages, each message denoting an event in the system. [...]
	</~~div~~>		</blockquote>
	~~<sup> </sup>~~
	<haskell>		::<haskell>
	type Channel a = [Event a]		type Channel a = [Event a]
	data Event a = At Time a		data Event a = At Time a
Line 170:		Line 170:
	* <small>(page 61)</small>		* <small>(page 61)</small>
	:{\|		:{\|
	\|<~~div style="border-left:1px solid lightgray; padding: 1em" alt="~~blockquote">		\|<blockquote>
	In the semantics given in Chapter 5 every <i>Ruth</i> program is supplied with a tree of time values (or clock) as suggested in [https://academic.oup.com/comjnl/article-pdf/31/3/243/1157325/310243.pdf this paper] and each <i>Ruth</i> process is given a different sub-tree of the clock [...]		In the semantics given in Chapter 5 every <i>Ruth</i> program is supplied with a tree of time values (or clock) as suggested in [https://academic.oup.com/comjnl/article-pdf/31/3/243/1157325/310243.pdf this paper] and each <i>Ruth</i> process is given a different sub-tree of the clock [...]
	</~~div~~>		</blockquote>
	~~<sup> </sup>~~
	<haskell>		::<haskell>
	type Program = Clock -> ...		type Program = Clock -> ...
	type Process a = Clock -> a		type Process a = Clock -> a
Line 182:		Line 182:
	right :: Clock -> Clock		right :: Clock -> Clock
	</haskell>		</haskell>
	~~<sup> </sup>~~
	<~~div style="border-left:1px solid lightgray; padding: 1em" alt="~~blockquote">		<blockquote>
	A clock tree is composed of a node holding a non-negative integer denoting the current time and two sub-trees containing the times of future events. As the tree is (lazily) evaluated each of the nodes is instantiated with the value of system time <i>at the time at which the node is instantiated</i>, thus giving programs reference to the current time. [...]		A clock tree is composed of a node holding a non-negative integer denoting the current time and two sub-trees containing the times of future events. As the tree is (lazily) evaluated each of the nodes is instantiated with the value of system time <i>at the time at which the node is instantiated</i>, thus giving programs reference to the current time. [...]
	</~~div~~>		</blockquote>
	~~<sup> </sup>~~
	<haskell>		::<haskell>
	type Time = Integer -- must be zero or larger		type Time = Integer -- must be zero or larger
	data Tree a = Node { contents :: a,		data Tree a = Node { contents :: a,
Line 199:		Line 199:

	Regarding Harrison's semantics:		Regarding Harrison's semantics:
	<~~div style="border-left:1px solid lightgray; padding: 1em" alt="~~blockquote"><small>(page 53)</small>
			<blockquote>
			<small>(page 53)</small>

	The semantics of <i>Ruth</i> given in Chapter 5 assume a normal order evaluation strategy such as is provided by the technique of lazy evaluation [...]. Consequently <code>whererec</code> can be used to define infinite data structures.		The semantics of <i>Ruth</i> given in Chapter 5 assume a normal order evaluation strategy such as is provided by the technique of lazy evaluation [...]. Consequently <code>whererec</code> can be used to define infinite data structures.
	</~~div~~>		</blockquote>

	[[Category:FRP\|*]]		[[Category:FRP\|*]]

Ysangkok: /* Blog posts */ fix link to luke palmer blog

2024-09-23T21:48:03Z

Blog posts: fix link to luke palmer blog

← Older revision		Revision as of 21:48, 23 September 2024
Line 131:		Line 131:
	* [http://conal.net/blog/tag/frp FRP-related posts on Conal Elliott’s blog]		* [http://conal.net/blog/tag/frp FRP-related posts on Conal Elliott’s blog]
	* [http://jeltsch.wordpress.com/tag/frp/ FRP-related posts on Wolfgang Jeltsch’s blog]		* [http://jeltsch.wordpress.com/tag/frp/ FRP-related posts on Wolfgang Jeltsch’s blog]
	* [http://lukepalmer.wordpress.com/2008/11/28/relative-time-frp/ Relative time FRP] by Luke Palmer		* [http://web.archive.org/web/20210420065305/https://lukepalmer.wordpress.com/2008/11/28/relative-time-frp/ Relative time FRP] by Luke Palmer (archived)
	* [http://blog.edwardamsden.com/2011/03/demonstrating-time-leak-in-arrowized.html Demonstrating a Time Leak in Arrowized FRP] by Edward Amsden		* [http://blog.edwardamsden.com/2011/03/demonstrating-time-leak-in-arrowized.html Demonstrating a Time Leak in Arrowized FRP] by Edward Amsden
	* [https://www.reddit.com/r/haskell/comments/3fr5ij/frp_systems_discussion/ FRP Systems discussion] on reddit		* [https://www.reddit.com/r/haskell/comments/3fr5ij/frp_systems_discussion/ FRP Systems discussion] on reddit

Atravers at 05:58, 7 November 2022

2022-11-07T05:58:29Z

← Older revision		Revision as of 05:58, 7 November 2022
Line 77:		Line 77:
	also appearing consecutively in time.		also appearing consecutively in time.

	<tt>~~<i>Process control via streams</i>, in~~ [https://repository.ubn.ru.nl/bitstream/handle/2066/17230/13246.pdf Functional Programming and Lambda Calculus], Henk Barendregt.</tt>		<tt>[https://repository.ubn.ru.nl/bitstream/handle/2066/17230/13246.pdf Functional Programming and Lambda Calculus], Henk Barendregt (page 325).</tt>
	</div>		</div>

Atravers at 02:14, 7 November 2022

2022-11-07T02:14:11Z

← Older revision		Revision as of 02:14, 7 November 2022
Line 66:		Line 66:
	</haskell>		</haskell>

	~~=== Streams ===~~		The concept of an <i>event stream</i> (or simply <i>stream</i>), for representing a series of events, supports a basic model of interactivity:

	~~A series of events is most easily represented as a list~~ of <~~code~~>~~Event~~</~~code~~>~~-values, commonly referred to as an ''event stream''~~ (or simply ~~a ''~~stream'')~~. It makes~~ for a ~~relatively-simple working~~ model:

	<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">		<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">
	Suppose that we want to compute a function <i>F</i> on several arguments		Suppose that we want to compute a function <i>F</i> on several arguments <i>A</i><sub>0</sub>, <i>A</i><sub>1</sub>, <i>A</i><sub>2</sub>,... appearing consecutively in time [as discrete events]. One can view this so-called <i>stream</i> (<i>A</i><sub>0</sub>, <i>A</i><sub>1</sub>, <i>A</i><sub>2</sub>,...) as a potentially infinite list <i>A</i> = (<i>A</i><sub>0</sub>:<i>A</i><sub>1</sub>:<i>A</i><sub>2</sub>:···:<i>A</i><sub>n</sub>:⊥) where ⊥ stands for “unspecified” and is interactively updated to <i>A</i><sub>n+1</sub>:⊥ each time the user has a new argument <i>A</i><sub>n+1</sub>. Then on this list <i>A</i>, the system applies the function <i>F</i><sup>*</sup> defined by
	<i>A</i><sub>0</sub>, <i>A</i><sub>1</sub>, <i>A</i><sub>2</sub>,... appearing consecutively in time. One can view this so-called <i>stream</i> (<i>A</i><sub>0</sub>, <i>A</i><sub>1</sub>, <i>A</i><sub>2</sub>,...) as a potentially infinite list <i>A</i> = (<i>A</i><sub>0</sub>:<i>A</i><sub>1</sub>:<i>A</i><sub>2</sub>:~~...~~:<i>A</i><sub>n</sub>:⊥) where ⊥ stands for “unspecified” and is interactively updated to <i>A</i><sub>n+1</sub>:⊥ each time the user has a new argument <i>A</i><sub>n+1</sub>. Then on this list <i>A</i>, the system applies the function <i>F</i><sup>*</sup> defined by
	::<i>F</i><sup></sup> (<i>A</i>:<i>B</i>) = (<i>F</i> <i>A</i>):(<i>F</i><sup></sup> <i>B</i>)		::<i>F</i><sup></sup> (<i>A</i>:<i>B</i>) = (<i>F</i> <i>A</i>):(<i>F</i><sup></sup> <i>B</i>)

	obtaining		obtaining
	::<i>F</i><sup></sup> <i>A</i> = (<i>F</i> <i>A</i><sub>0</sub>:<i>F</i> <i>A</i><sub>1</sub>:<i>F</i> <i>A</i><sub>2</sub>:~~...~~:<i>F</i> <i>A</i><sub>n</sub>:<i>F</i><sup></sup> ⊥)		::<i>F</i><sup></sup> <i>A</i> = (<i>F</i> <i>A</i><sub>0</sub>:<i>F</i> <i>A</i><sub>1</sub>:<i>F</i> <i>A</i><sub>2</sub>:···:<i>F</i> <i>A</i><sub>n</sub>:<i>F</i><sup></sup> ⊥)

	also appearing consecutively in time.		also appearing consecutively in time.

Atravers at 22:50, 5 November 2022

2022-11-05T22:50:21Z

@@ Line 66: / Line 66: @@
 </haskell>
-A series of events is most easily represented as a list of <code>Event</code>-values, commonly referred to as an ''event stream'' (or simply a ''stream'').
+=== Streams ===
 == Semantic functions? ==

Atravers at 07:45, 17 August 2022

2022-08-17T07:45:18Z

← Older revision		Revision as of 07:45, 17 August 2022
Line 147:		Line 147:
	:{\|		:{\|
	\|<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">		\|<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">
	A channel is an infinite stream of timestamped data values, or messages, each message denoting an event in the system.		A channel is an infinite stream of timestamped data values, or messages, each message denoting an event in the system. [...]
	</div>		</div>
	<sup> </sup>		<sup> </sup>

Atravers: >_<

2022-08-17T07:43:47Z

>_<

← Older revision		Revision as of 07:43, 17 August 2022
Line 169:		Line 169:
	left :: Clock -> Clock		left :: Clock -> Clock
	right :: Clock -> Clock		right :: Clock -> Clock
	~~type Process a = Clock -> a~~
	</haskell>		</haskell>
	<sup> </sup>		<sup> </sup>

Atravers: New section added; formatting changes; various corrections >_<

2022-08-17T07:40:34Z

New section added; formatting changes; various corrections >_<

← Older revision		Revision as of 07:40, 17 August 2022
Line 67:		Line 67:

	A series of events is most easily represented as a list of <code>Event</code>-values, commonly referred to as an ''event stream'' (or simply a ''stream'').		A series of events is most easily represented as a list of <code>Event</code>-values, commonly referred to as an ''event stream'' (or simply a ''stream'').

			== Semantic functions? ==

			From page 6 of [http://conal.net/papers/icfp97/icfp97.pdf the paper]:
			<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">
			An early implementation of Fran represented behaviors as implied in the formal semantics:
			<haskell>
			data Behavior a = Behavior (Time -> a)
			</haskell>
			This representation, however, leads to a serious inefficiency [a “space-time” leak].
			</div>

			So instead of one canonical implementation of FRP, this tendency to "leak" has led to a variety of implementations, each with its own benefit-cost trade-offs.

	== Libraries ==		== Libraries ==
Line 131:		Line 144:
	In his thesis [https://core.ac.uk/download/9835633.pdf Functional Real-Time Programming: The Language Ruth And Its Semantics], some parts of the semantics Dave Harrison gives for ''Ruth'' bears a curious resemblance to those for FRP:		In his thesis [https://core.ac.uk/download/9835633.pdf Functional Real-Time Programming: The Language Ruth And Its Semantics], some parts of the semantics Dave Harrison gives for ''Ruth'' bears a curious resemblance to those for FRP:

	* ~~from~~ page 48:		* <small>(page 48)</small>
	:{\|		:{\|
	\|<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">		\|<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">
Line 139:		Line 152:
	<haskell>		<haskell>
	type Channel a = [Event a]		type Channel a = [Event a]
			data Event a = At Time a
	</haskell>		</haskell>
	\|}		\|}

	* ~~from~~ page ~~50:~~		* <small>(page 61)</small>
	:{\|		:{\|
	\|<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">		\|<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">
	~~A unique clock~~ is ~~automatically~~ supplied to each Ruth process ~~at run~~-~~time, to provide real-time information,~~ [...]		In the semantics given in Chapter 5 every <i>Ruth</i> program is supplied with a tree of time values (or clock) as suggested in [https://academic.oup.com/comjnl/article-pdf/31/3/243/1157325/310243.pdf this paper] and each <i>Ruth</i> process is given a different sub-tree of the clock [...]
	</div>		</div>
	<sup> </sup>		<sup> </sup>
	<haskell>		<haskell>
			type Program = Clock -> ...
			type Process a = Clock -> a

			type Clock = Tree Time
			left :: Clock -> Clock
			right :: Clock -> Clock
	type Process a = Clock -> a		type Process a = Clock -> a
	</haskell>		</haskell>
			<sup> </sup>
	~~where a~~ <~~code~~>~~Clock~~</~~code~~> ~~value~~ is a tree of time~~-values~~, ~~rather than~~ the ~~direct use of~~ time~~-values in FRP:~~		<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote">
			A clock tree is composed of a node holding a non-negative integer denoting the current time and two sub-trees containing the times of future events. As the tree is (lazily) evaluated each of the nodes is instantiated with the value of system time <i>at the time at which the node is instantiated</i>, thus giving programs reference to the current time. [...]
			</div>
			<sup> </sup>
	<haskell>		<haskell>
	~~-- from page 61~~		type Time = Integer -- must be zero or larger
	~~type Clock = Tree Time~~
	type Time = Integer -- must be zero or larger

	data Tree a = Node { contents :: a,		data Tree a = Node { contents :: a,
	left :: Tree a,		left :: Tree a,
	right :: Tree a }		right :: Tree a }

			currentTime :: Clock -> Time
			currentTime = contents
	</haskell>		</haskell>
	\|}		\|}

	~~As a ''Ruth~~'~~' process runs, the nodes of the clock are used incrementally~~:		Regarding Harrison's semantics:
	* to ascertain the current time (<~~code~~>~~contents~~</~~code~~>~~), and~~		<div style="border-left:1px solid lightgray; padding: 1em" alt="blockquote"><small>(page 53)</small>
	* to provide other clocks for use elsewhere (<~~code~~>~~left~~</~~code~~> ~~and~~ <code>~~right~~</code>).
			The semantics of <i>Ruth</i> given in Chapter 5 assume a normal order evaluation strategy such as is provided by the technique of lazy evaluation [...]. Consequently <code>whererec</code> can be used to define infinite data structures.
			</div>

	[[Category:FRP\|*]]		[[Category:FRP\|*]]