<?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: Sequences, streams, and segments</title>
	<atom:link href="http://conal.net/blog/posts/sequences-streams-and-segments/feed" rel="self" type="application/rss+xml" />
	<link>http://conal.net/blog/posts/sequences-streams-and-segments</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: Conal Elliott &#187; Blog Archive &#187; Sequences, segments, and signals</title>
		<link>http://conal.net/blog/posts/sequences-streams-and-segments#comment-247</link>
		<dc:creator><![CDATA[Conal Elliott &#187; Blog Archive &#187; Sequences, segments, and signals]]></dc:creator>
		<pubDate>Sat, 09 Jan 2010 02:17:33 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=65#comment-247</guid>
		<description><![CDATA[&lt;p&gt;[...] post Sequences, streams, and segments offered an answer to the the question of what&#8217;s missing in the following box:   [...]&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>[&#8230;] post Sequences, streams, and segments offered an answer to the the question of what&#8217;s missing in the following box:   [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: geophf</title>
		<link>http://conal.net/blog/posts/sequences-streams-and-segments#comment-246</link>
		<dc:creator><![CDATA[geophf]]></dc:creator>
		<pubDate>Mon, 29 Jun 2009 23:37:45 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=65#comment-246</guid>
		<description><![CDATA[&lt;p&gt;Hello, Conal,&lt;/p&gt;

&lt;p&gt;I liked your discussion about comonads, and, as I used the concept to describe &quot;realized&quot; constants, I linked your post into my article &quot;&lt;a href=&quot;http://logicaltypes.blogspot.com/2009/06/realized-constants-are-comonadic.html&quot; rel=&quot;nofollow&quot;&gt;Realized Constants are Comonadic&lt;/a&gt;&quot;.&lt;/p&gt;

&lt;p&gt;I had started exploring comonadic structures before for you posted your description, and I felt the loss, as they are a really simple concept, but other than Edward Kmett&#039;s (very excellent) site and sigfpe&#039;s blog, there seemed to be little interest in them.&lt;/p&gt;

&lt;p&gt;Thank you for bringing this useful concept to the fore.&lt;/p&gt;

&lt;p&gt;cheers, geophf&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Hello, Conal,</p>

<p>I liked your discussion about comonads, and, as I used the concept to describe &#8220;realized&#8221; constants, I linked your post into my article &#8220;<a href="http://logicaltypes.blogspot.com/2009/06/realized-constants-are-comonadic.html" rel="nofollow">Realized Constants are Comonadic</a>&#8220;.</p>

<p>I had started exploring comonadic structures before for you posted your description, and I felt the loss, as they are a really simple concept, but other than Edward Kmett&#8217;s (very excellent) site and sigfpe&#8217;s blog, there seemed to be little interest in them.</p>

<p>Thank you for bringing this useful concept to the fore.</p>

<p>cheers, geophf</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: conal</title>
		<link>http://conal.net/blog/posts/sequences-streams-and-segments#comment-245</link>
		<dc:creator><![CDATA[conal]]></dc:creator>
		<pubDate>Wed, 03 Dec 2008 02:19:24 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=65#comment-245</guid>
		<description><![CDATA[&lt;p&gt;Thanks bunches for the tip, Luke!&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Thanks bunches for the tip, Luke!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luke Palmer</title>
		<link>http://conal.net/blog/posts/sequences-streams-and-segments#comment-244</link>
		<dc:creator><![CDATA[Luke Palmer]]></dc:creator>
		<pubDate>Wed, 03 Dec 2008 02:09:28 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=65#comment-244</guid>
		<description><![CDATA[&lt;p&gt;Oh, another note, regarding the comonad laws.  While whatever work you might do to prove that your code is correct will entail this, it might be helpful anyway.  Your representation for reactive is Reactive A = A * Future (Reactive A), which is the cofree comonad over the Future functor, which always satisfies the comonad laws.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>Oh, another note, regarding the comonad laws.  While whatever work you might do to prove that your code is correct will entail this, it might be helpful anyway.  Your representation for reactive is Reactive A = A * Future (Reactive A), which is the cofree comonad over the Future functor, which always satisfies the comonad laws.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luke Palmer</title>
		<link>http://conal.net/blog/posts/sequences-streams-and-segments#comment-243</link>
		<dc:creator><![CDATA[Luke Palmer]]></dc:creator>
		<pubDate>Wed, 03 Dec 2008 01:27:35 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=65#comment-243</guid>
		<description><![CDATA[&lt;p&gt;@Paul:  I played with causal arrows a while ago.  But there was no unit step or any such thing in the formalism.  My definition was that a transformation R of time functions is causal if it satisfies R(f)_t = R(f_t)_t, where _t means roughly &quot;restricted to times after t&quot;.  It&#039;s a pretty weak constraint, and can be formalized (after redefining &quot;after&quot;) even in relativistic (as in Einstein) systems :-).  I do think causality is a big deal in FRP, and capturing it properly will be key to its full potential.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>@Paul:  I played with causal arrows a while ago.  But there was no unit step or any such thing in the formalism.  My definition was that a transformation R of time functions is causal if it satisfies R(f)_t = R(f_t)_t, where _t means roughly &#8220;restricted to times after t&#8221;.  It&#8217;s a pretty weak constraint, and can be formalized (after redefining &#8220;after&#8221;) even in relativistic (as in Einstein) systems :-).  I do think causality is a big deal in FRP, and capturing it properly will be key to its full potential.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: conal</title>
		<link>http://conal.net/blog/posts/sequences-streams-and-segments#comment-242</link>
		<dc:creator><![CDATA[conal]]></dc:creator>
		<pubDate>Tue, 02 Dec 2008 03:08:40 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=65#comment-242</guid>
		<description><![CDATA[&lt;p&gt;@Paul: Thanks for the hunch about &lt;code&gt;((:-&gt;#) t)&lt;/code&gt; satisfying the comonad laws.&lt;/p&gt;

&lt;p&gt;I like your question about relating our abstractions to standard algebraic notions embodied by type classes.
I appreciate the &quot;syntactic&quot; (so to speak) and semantic benefits.
By syntactic, I mean inheriting a standard vocabulary so that I don&#039;t have to define so much of it myself.
That vocabulary guides me to tools that I might not have thought to try out.
By &quot;semantic benefits&quot;, I mean both the class laws, as you mentioned, and the &lt;a href=&quot;http://conal.net/blog/tag/morphism/&quot; rel=&quot;nofollow&quot;&gt;semantic morphisms&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;For instance, much of the syntactic and semantic foundation of FRP (the explicit signal variety) can be captured via class instances and the corresponding type class morphisms.
When those morphisms hold, I know I&#039;m in the universal flow, rather than just making stuff up.
I&#039;m confident that my formalism will be powerful, predictable, and a pleasure to use.
When the morphisms fail, or aren&#039;t even defined, as currently with Reactive events, I know to expect pain and where to start when trying to improve things.&lt;/p&gt;

&lt;p&gt;For signals in particular, &lt;code&gt;Applicative&lt;/code&gt; has been great, since it (or &lt;code&gt;Zip&lt;/code&gt;) captures the essence of concurrent composition.
And the semantic model and applicative morphism tell us exactly what the &lt;code&gt;Applicative&lt;/code&gt; instance must mean.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>@Paul: Thanks for the hunch about <code>((:-&gt;#) t)</code> satisfying the comonad laws.</p>

<p>I like your question about relating our abstractions to standard algebraic notions embodied by type classes.
I appreciate the &#8220;syntactic&#8221; (so to speak) and semantic benefits.
By syntactic, I mean inheriting a standard vocabulary so that I don&#8217;t have to define so much of it myself.
That vocabulary guides me to tools that I might not have thought to try out.
By &#8220;semantic benefits&#8221;, I mean both the class laws, as you mentioned, and the <a href="http://conal.net/blog/tag/morphism/" rel="nofollow">semantic morphisms</a>.</p>

<p>For instance, much of the syntactic and semantic foundation of FRP (the explicit signal variety) can be captured via class instances and the corresponding type class morphisms.
When those morphisms hold, I know I&#8217;m in the universal flow, rather than just making stuff up.
I&#8217;m confident that my formalism will be powerful, predictable, and a pleasure to use.
When the morphisms fail, or aren&#8217;t even defined, as currently with Reactive events, I know to expect pain and where to start when trying to improve things.</p>

<p>For signals in particular, <code>Applicative</code> has been great, since it (or <code>Zip</code>) captures the essence of concurrent composition.
And the semantic model and applicative morphism tell us exactly what the <code>Applicative</code> instance must mean.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Liu</title>
		<link>http://conal.net/blog/posts/sequences-streams-and-segments#comment-241</link>
		<dc:creator><![CDATA[Paul Liu]]></dc:creator>
		<pubDate>Tue, 02 Dec 2008 02:40:14 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=65#comment-241</guid>
		<description><![CDATA[&lt;p&gt;@Conal, I think ((:-&gt;#) t) would satisfy comonad laws due to the way duplicate is defined, which indeed enforces a moving position by dropping &quot;the past&quot;.&lt;/p&gt;

&lt;p&gt;A question I&#039;m always asking myself is that, do we gain anything from declaring signals (both behaviors and events) an instance of such abstract formalisms like Comonad or Applicative Functor?&lt;/p&gt;

&lt;p&gt;Sure, we get a few primitives to write program with and some nice properties (i.e., the laws) associated with them. But do they help? To what extent?&lt;/p&gt;

&lt;p&gt;I for one do not think Applicative Functor provides any more insights than Functors except some coding convenience perhaps. As for Comonad, I don&#039;t know, the laws are actually more interesting than those of Applicative Functors, but I&#039;m not sure how to make use of them.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>@Conal, I think ((:-&gt;#) t) would satisfy comonad laws due to the way duplicate is defined, which indeed enforces a moving position by dropping &#8220;the past&#8221;.</p>

<p>A question I&#8217;m always asking myself is that, do we gain anything from declaring signals (both behaviors and events) an instance of such abstract formalisms like Comonad or Applicative Functor?</p>

<p>Sure, we get a few primitives to write program with and some nice properties (i.e., the laws) associated with them. But do they help? To what extent?</p>

<p>I for one do not think Applicative Functor provides any more insights than Functors except some coding convenience perhaps. As for Comonad, I don&#8217;t know, the laws are actually more interesting than those of Applicative Functors, but I&#8217;m not sure how to make use of them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steven Fodstad</title>
		<link>http://conal.net/blog/posts/sequences-streams-and-segments#comment-240</link>
		<dc:creator><![CDATA[Steven Fodstad]]></dc:creator>
		<pubDate>Tue, 02 Dec 2008 01:19:42 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=65#comment-240</guid>
		<description><![CDATA[&lt;p&gt;The dual to the statement &quot;Nothing escapes a monad&quot; is the statement &quot;Nothing can create a comonad&quot;.  And just as every monad needs to have a method to violate that rule in order to be useful (State has runState; lists have head and (!!); IO can be executed), every comonad needs to have a way to create a value (most likely more than one way) in order to be useful.  These functions will not be modeled by the comonad interface.&lt;/p&gt;

&lt;p&gt;I think choosing a proper set of functions that create comonadic values (other than what&#039;s provided in the definition of a comonad) should be enough to enforce causality.  I haven&#039;t done enough work on this to say for certain, though.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>The dual to the statement &#8220;Nothing escapes a monad&#8221; is the statement &#8220;Nothing can create a comonad&#8221;.  And just as every monad needs to have a method to violate that rule in order to be useful (State has runState; lists have head and (!!); IO can be executed), every comonad needs to have a way to create a value (most likely more than one way) in order to be useful.  These functions will not be modeled by the comonad interface.</p>

<p>I think choosing a proper set of functions that create comonadic values (other than what&#8217;s provided in the definition of a comonad) should be enough to enforce causality.  I haven&#8217;t done enough work on this to say for certain, though.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: conal</title>
		<link>http://conal.net/blog/posts/sequences-streams-and-segments#comment-239</link>
		<dc:creator><![CDATA[conal]]></dc:creator>
		<pubDate>Mon, 01 Dec 2008 18:36:23 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=65#comment-239</guid>
		<description><![CDATA[&lt;p&gt;@Paul:
Thanks for the reminder to check the comonad laws, which I haven&#039;t done yet.
Do you think &lt;code&gt;((:-&gt;#) t)&lt;/code&gt; passes or fails?&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>@Paul:
Thanks for the reminder to check the comonad laws, which I haven&#8217;t done yet.
Do you think <code>((:-&gt;#) t)</code> passes or fails?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: conal</title>
		<link>http://conal.net/blog/posts/sequences-streams-and-segments#comment-238</link>
		<dc:creator><![CDATA[conal]]></dc:creator>
		<pubDate>Mon, 01 Dec 2008 18:29:59 +0000</pubDate>
		<guid isPermaLink="false">http://conal.net/blog/?p=65#comment-238</guid>
		<description><![CDATA[&lt;p&gt;@Eyal: Thanks for the suggestion.
I hadn&#039;t thought of splitting up the &lt;code&gt;Segment&lt;/code&gt; class.
&lt;code&gt;drop&lt;/code&gt; could indeed go into another class, since it works for infinite-only types like &lt;code&gt;(t -&gt; a)&lt;/code&gt; (for ordered infinite &lt;code&gt;t&lt;/code&gt;) as well as for possibly-finite ones like &lt;code&gt;[a]&lt;/code&gt; and &lt;code&gt;(t :-&gt;# a)&lt;/code&gt;.
&lt;code&gt;take&lt;/code&gt; yields a finite result, so I think would be problematic.&lt;/p&gt;
]]></description>
		<content:encoded><![CDATA[<p>@Eyal: Thanks for the suggestion.
I hadn&#8217;t thought of splitting up the <code>Segment</code> class.
<code>drop</code> could indeed go into another class, since it works for infinite-only types like <code>(t -&gt; a)</code> (for ordered infinite <code>t</code>) as well as for possibly-finite ones like <code>[a]</code> and <code>(t :-&gt;# a)</code>.
<code>take</code> yields a finite result, so I think would be problematic.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
