On Sat, Jan 17, 2009 at 5:04 AM, Andrew Coppin <span dir="ltr">&lt;<a href="mailto:andrewcoppin@btinternet.com">andrewcoppin@btinternet.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Eugene Kirpichov wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
No, a functor is a more wide notion than that, it has nothing to do<br>
with collections.<br>
An explanation more close to truth would be &quot;A structure is a functor<br>
if it provides a way to convert a structure over X to a structure over<br>
Y, given a function X -&gt; Y, while preserving the underlying<br>
&#39;structure&#39;&quot;, where preserving structure means being compatible with<br>
composition and identity.<br>
 &nbsp;<br>
</blockquote>
<br>
As far as I&#39;m aware, constraints like &quot;while preserving the underlying structure&quot; are not expressible in Haskell.</blockquote><div><br>Well, they&#39;re expressible <i>about</i> Haskell.&nbsp; I.e., for functors we require:<br>
<br>&nbsp; fmap id = id<br>&nbsp; fmap (f . g) = fmap f . fmap g<br><br>&nbsp;The first property is how we write &quot;preserving underlying structure&quot;, but this has a precise, well-defined meaning that we can say a given functor obeys or it does not (and if it does not, we say that it&#39;s a bad instance).&nbsp; But you are correct that Haskell does not allow us to require proofs of such properties.<br>
<br>And indeed, some people break those properties in various ways, which some consider okay if the breakage is not observable from outside a given abstraction barrier.&nbsp; I&#39;m on the fence about that...<br><br></div></div>
Luke<br>