On Sat, Jan 17, 2009 at 5:04 AM, Andrew Coppin <span dir="ltr"><<a href="mailto:andrewcoppin@btinternet.com">andrewcoppin@btinternet.com</a>></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 "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 -> Y, while preserving the underlying<br>
'structure'", where preserving structure means being compatible with<br>
composition and identity.<br>
<br>
</blockquote>
<br>
As far as I'm aware, constraints like "while preserving the underlying structure" are not expressible in Haskell.</blockquote><div><br>Well, they're expressible <i>about</i> Haskell. I.e., for functors we require:<br>
<br> fmap id = id<br> fmap (f . g) = fmap f . fmap g<br><br> The first property is how we write "preserving underlying structure", 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's a bad instance). 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. I'm on the fence about that...<br><br></div></div>
Luke<br>