<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>Comments on: Garbage collecting the semantics of FRP</title>
	<atom:link href="http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp/feed" rel="self" type="application/rss+xml" />
	<link>http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp</link>
	<description>Inspirations &#38; experiments, mainly about denotative/functional programming in Haskell</description>
	<lastBuildDate>Sat, 26 Sep 2020 21:06:12 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=4.1.17</generator>
	<item>
		<title>By: Sjoerd Visscher</title>
		<link>http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp#comment-583</link>
		<dc:creator><![CDATA[Sjoerd Visscher]]></dc:creator>
		<pubDate>Mon, 21 Nov 2011 12:42:05 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=96#comment-583</guid>
		<description><![CDATA[&lt;p&gt;You might be interested in this: http://www.reddit.com/r/haskell/comments/mj23v/new_video_lecture_how_to_be_more_productive/&lt;/p&gt;

&lt;p&gt;I wonder if it is possible (or makes sense even) to apply the Banach fixed-point theorem to the continuous time model.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>You might be interested in this: <a href="http://www.reddit.com/r/haskell/comments/mj23v/new_video_lecture_how_to_be_more_productive/" rel="nofollow">http://www.reddit.com/r/haskell/comments/mj23v/new_video_lecture_how_to_be_more_productive/</a></p>

<p>I wonder if it is possible (or makes sense even) to apply the Banach fixed-point theorem to the continuous time model.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: A Model for Denotative Continuous-Time Programming &#171; Jake McArthur</title>
		<link>http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp#comment-582</link>
		<dc:creator><![CDATA[A Model for Denotative Continuous-Time Programming &#171; Jake McArthur]]></dc:creator>
		<pubDate>Sun, 03 Apr 2011 17:59:09 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=96#comment-582</guid>
		<description><![CDATA[&lt;p&gt;[...] Garbage Collecting the Semantics of FRP, Conal muses over some of the issues with the semantics of DCTP. He explains that both classic and [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] Garbage Collecting the Semantics of FRP, Conal muses over some of the issues with the semantics of DCTP. He explains that both classic and [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: conal</title>
		<link>http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp#comment-581</link>
		<dc:creator><![CDATA[conal]]></dc:creator>
		<pubDate>Sun, 03 Apr 2011 17:04:39 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=96#comment-581</guid>
		<description><![CDATA[&lt;p&gt;Lambdor: I&#039;m with you on both counts. For some related remarks, see the post &lt;a href=&quot;http://conal.net/blog/posts/why-classic-FRP-does-not-fit-interactive-behavior/&quot; rel=&quot;nofollow&quot;&gt;&lt;em&gt;Why classic FRP does not fit interactive behavior&lt;/em&gt;&lt;/a&gt;.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Lambdor: I&#8217;m with you on both counts. For some related remarks, see the post <a href="http://conal.net/blog/posts/why-classic-FRP-does-not-fit-interactive-behavior/" rel="nofollow"><em>Why classic FRP does not fit interactive behavior</em></a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lambdor</title>
		<link>http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp#comment-580</link>
		<dc:creator><![CDATA[Lambdor]]></dc:creator>
		<pubDate>Tue, 22 Mar 2011 20:56:15 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=96#comment-580</guid>
		<description><![CDATA[&lt;p&gt;In game development I think we would very much like to go forward and backward in time and skew it (see games like Braid, the new Prince of Persia, Max Payne etc.) but maybe this is a totally different aspect which should be covered by some sort of &quot;recording&quot;.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>In game development I think we would very much like to go forward and backward in time and skew it (see games like Braid, the new Prince of Persia, Max Payne etc.) but maybe this is a totally different aspect which should be covered by some sort of &#8220;recording&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wolf Tivy</title>
		<link>http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp#comment-579</link>
		<dc:creator><![CDATA[Wolf Tivy]]></dc:creator>
		<pubDate>Mon, 31 May 2010 20:32:51 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=96#comment-579</guid>
		<description><![CDATA[&lt;p&gt;In control theory, we use the Laplace Transform to turn time (t) domain integral and differential equations into frequency (s) domain &quot;transfer functions&quot;. There is some amount of non-causality in the definition of s and the Laplace Transform, as it involves integration over t=0..inf, but I think it is is very easy to restrict.&lt;/p&gt;

&lt;p&gt;In the time domain, differentiation and integration are difficult to compute and composing systems involves the usual gymnastics. In the s domain however, a differentiator is just D(s)=s, an integrator is I(s)=1/s, and composition is just multiplication.&lt;/p&gt;

&lt;p&gt;The point of all this is that the s-domain somehow encapsulates all derivatives and integrals into one complex number to allow any causal system to be defined as a simple Complex-&gt;Complex. This seems to be what you are looking for, specifically the &quot;behaviors are some sort of function with all of its derivatives&quot; part.&lt;/p&gt;

&lt;p&gt;I have been trying to apply these (control theory) ideas to FRP ever since I discovered FRP. The kinks are in a) Trying to connect s-domain transfer functions to time domain data streams (I think MATLAB (simulink) does it somehow). b) Extending the concept to arbitrary data (not just vectors of complex). And c) Somehow coping with dynamically determined transfer function networks. If you could work out these issues I think you would have a the right model for FRP.&lt;/p&gt;

&lt;p&gt;The laplace transform seems to deal with discontinuities fairly well; the laplace transform of the delayed unit step is just Del(s)=exp(s-a) or something, though again, how to connect this to the outside world is unknown to me.&lt;/p&gt;

&lt;p&gt;I think it would be a good idea to look into control theory for some ideas, even if the laplace transform and the s domain cant be used directly. The concept of using arbitrary access to past and future (at least in an abstract denonational sense) and then encapsulating it into some parameter might be useful for FRP.&lt;/p&gt;

&lt;p&gt;I hope this is helpful. Good Luck.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>In control theory, we use the Laplace Transform to turn time (t) domain integral and differential equations into frequency (s) domain &#8220;transfer functions&#8221;. There is some amount of non-causality in the definition of s and the Laplace Transform, as it involves integration over t=0..inf, but I think it is is very easy to restrict.</p>

<p>In the time domain, differentiation and integration are difficult to compute and composing systems involves the usual gymnastics. In the s domain however, a differentiator is just D(s)=s, an integrator is I(s)=1/s, and composition is just multiplication.</p>

<p>The point of all this is that the s-domain somehow encapsulates all derivatives and integrals into one complex number to allow any causal system to be defined as a simple Complex-&gt;Complex. This seems to be what you are looking for, specifically the &#8220;behaviors are some sort of function with all of its derivatives&#8221; part.</p>

<p>I have been trying to apply these (control theory) ideas to FRP ever since I discovered FRP. The kinks are in a) Trying to connect s-domain transfer functions to time domain data streams (I think MATLAB (simulink) does it somehow). b) Extending the concept to arbitrary data (not just vectors of complex). And c) Somehow coping with dynamically determined transfer function networks. If you could work out these issues I think you would have a the right model for FRP.</p>

<p>The laplace transform seems to deal with discontinuities fairly well; the laplace transform of the delayed unit step is just Del(s)=exp(s-a) or something, though again, how to connect this to the outside world is unknown to me.</p>

<p>I think it would be a good idea to look into control theory for some ideas, even if the laplace transform and the s domain cant be used directly. The concept of using arbitrary access to past and future (at least in an abstract denonational sense) and then encapsulating it into some parameter might be useful for FRP.</p>

<p>I hope this is helpful. Good Luck.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Point-wise FRP, plus memory &#8211; Part 1 &#171; Noam Lewis</title>
		<link>http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp#comment-578</link>
		<dc:creator><![CDATA[Point-wise FRP, plus memory &#8211; Part 1 &#171; Noam Lewis]]></dc:creator>
		<pubDate>Sun, 21 Mar 2010 00:51:13 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=96#comment-578</guid>
		<description><![CDATA[&lt;p&gt;[...] FRP, plus memory &#8211; Part&#160;1 By sinelaw  After Conal&#8217;s blog post, I&#8217;ve been thinking about possible models of FRP that satisfy the &#8220;no arbitrary time [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] FRP, plus memory &#8211; Part&nbsp;1 By sinelaw  After Conal&#8217;s blog post, I&#8217;ve been thinking about possible models of FRP that satisfy the &#8220;no arbitrary time [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason Stumpf</title>
		<link>http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp#comment-577</link>
		<dc:creator><![CDATA[Jason Stumpf]]></dc:creator>
		<pubDate>Tue, 09 Mar 2010 23:08:02 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=96#comment-577</guid>
		<description><![CDATA[&lt;p&gt;Working on my own I came up with basically the same thing as Yair, but without anything in hackage yet.&lt;/p&gt;

&lt;p&gt;&lt;code&gt;
data Reaction t a b = Reaction [(t,b)] ((t,a) -&gt; Reaction t a b)
&lt;/code&gt;&lt;/p&gt;

&lt;p&gt;t is the type of time.  A Reaction has [(t,b)] the events that would come out if no events went in (where each t is the time that has passed since the last event, or since this reaction began in the case of the first event), and ((t,a) -&gt; Reaction t a b) how it responds to an event after a certain amount of time.&lt;/p&gt;

&lt;p&gt;I&#039;m tentatively considering continuous time as events of behaviors, with behaviors represented as (t -&gt; b) functions.  When the event happens, the continuous behavior begins, when the next event happens, a new continuous behavior begins.  This does allow one to use the future and the past, but only as though no events happened or will happen.  The way I see it, this is similar to Conal&#039;s idea of nature, since from a tower of derivatives you can get the behavior function to high precision at any time, but not through discontinuities.  If a stone is thrown, we know where it will land, unless a bird grabs it.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Working on my own I came up with basically the same thing as Yair, but without anything in hackage yet.</p>

<p><code>
data Reaction t a b = Reaction [(t,b)] ((t,a) -&gt; Reaction t a b)
</code></p>

<p>t is the type of time.  A Reaction has [(t,b)] the events that would come out if no events went in (where each t is the time that has passed since the last event, or since this reaction began in the case of the first event), and ((t,a) -&gt; Reaction t a b) how it responds to an event after a certain amount of time.</p>

<p>I&#8217;m tentatively considering continuous time as events of behaviors, with behaviors represented as (t -&gt; b) functions.  When the event happens, the continuous behavior begins, when the next event happens, a new continuous behavior begins.  This does allow one to use the future and the past, but only as though no events happened or will happen.  The way I see it, this is similar to Conal&#8217;s idea of nature, since from a tower of derivatives you can get the behavior function to high precision at any time, but not through discontinuities.  If a stone is thrown, we know where it will land, unless a bird grabs it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Henrik Nilsson</title>
		<link>http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp#comment-576</link>
		<dc:creator><![CDATA[Henrik Nilsson]]></dc:creator>
		<pubDate>Sun, 07 Feb 2010 21:37:02 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=96#comment-576</guid>
		<description><![CDATA[&lt;p&gt;Hi Conal,&lt;/p&gt;

&lt;p&gt;You write:&lt;/p&gt;

&lt;p&gt;Instead, the abstraction is a signal transformer, SF a b, whose semantics is (T-&gt;a) -&gt; (T-&gt;b). See Genuinely Functional
   User Interfaces and Functional Reactive Programming, Continued.&lt;/p&gt;

&lt;p&gt;Note that the Yampa papes always insisted this was just a conceptual definition to convey the basic intuitions, a first approximation: Yampa&#039;s signal functions were always &lt;em&gt;causal&lt;/em&gt; by construction, which the FRP Continued paper does state explicitly, and the reason was preciciely to rule out the &quot;junk&quot;, i.e. the signal function we cannot hope to implement in a reactive setting where the input is only revealed as time progresses. The approximate nature of this intuitive definition of signal functions was made even more explicit in later papers by using the &quot;apprixmately equal&quot; symbol in the definition, and even later papers by Neil Sculthorpe and myself has elaboated further on the point of casuality (and other useful temporal properties).&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Hi Conal,</p>

<p>You write:</p>

<p>Instead, the abstraction is a signal transformer, SF a b, whose semantics is (T-&gt;a) -&gt; (T-&gt;b). See Genuinely Functional
   User Interfaces and Functional Reactive Programming, Continued.</p>

<p>Note that the Yampa papes always insisted this was just a conceptual definition to convey the basic intuitions, a first approximation: Yampa&#8217;s signal functions were always <em>causal</em> by construction, which the FRP Continued paper does state explicitly, and the reason was preciciely to rule out the &#8220;junk&#8221;, i.e. the signal function we cannot hope to implement in a reactive setting where the input is only revealed as time progresses. The approximate nature of this intuitive definition of signal functions was made even more explicit in later papers by using the &#8220;apprixmately equal&#8221; symbol in the definition, and even later papers by Neil Sculthorpe and myself has elaboated further on the point of casuality (and other useful temporal properties).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Frederick Ross</title>
		<link>http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp#comment-575</link>
		<dc:creator><![CDATA[Frederick Ross]]></dc:creator>
		<pubDate>Tue, 19 Jan 2010 16:58:05 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=96#comment-575</guid>
		<description><![CDATA[&lt;p&gt;I&#039;ve been playing with this and do you really need integration?  I feel like you might make something of unification.  For example, say you have two text boxes and a button that&#039;s supposed to swap the values in them,&lt;/p&gt;

&lt;p&gt;(val1, val2, True) :- (val2, val1, False) &lt;code&gt;x&lt;/code&gt; (textBox, textBox, button).&lt;/p&gt;

&lt;p&gt;where you unify forwards in time, and the program makes some attempt to use the latest state possible for any given unification.&lt;/p&gt;

&lt;p&gt;I suppose it&#039;s not really FRP if you do it that way, though...&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>I&#8217;ve been playing with this and do you really need integration?  I feel like you might make something of unification.  For example, say you have two text boxes and a button that&#8217;s supposed to swap the values in them,</p>

<p>(val1, val2, True) :- (val2, val1, False) <code>x</code> (textBox, textBox, button).</p>

<p>where you unify forwards in time, and the program makes some attempt to use the latest state possible for any given unification.</p>

<p>I suppose it&#8217;s not really FRP if you do it that way, though&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Beliefs and the Unimpossibility of Functional Reactive Programming &#171; Luke Palmer</title>
		<link>http://conal.net/blog/posts/garbage-collecting-the-semantics-of-frp#comment-574</link>
		<dc:creator><![CDATA[Beliefs and the Unimpossibility of Functional Reactive Programming &#171; Luke Palmer]]></dc:creator>
		<pubDate>Sun, 17 Jan 2010 05:18:23 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=96#comment-574</guid>
		<description><![CDATA[&lt;p&gt;[...] and the rest of the FRP gang has been discussing the semantic junk in classic FRP. Clearly there is more (or rather, less) to an interactive Behavior than an [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] and the rest of the FRP gang has been discussing the semantic junk in classic FRP. Clearly there is more (or rather, less) to an interactive Behavior than an [&#8230;]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
