<br><br><div><span class="gmail_quote">On 3/27/07, <b class="gmail_sendername">Dan Piponi</b> <<a href="mailto:dpiponi@gmail.com">dpiponi@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 3/27/07, <a href="mailto:Dave@haskell.org">Dave@haskell.org</a> <<a href="mailto:Dave@haskell.org">Dave@haskell.org</a>> wrote:<br>> Given the amount of material posted at <a href="http://haskell.org">haskell.org
</a> and elsewhere<br>> explaining IO, monads and functors, has anyone considered publishing<br>> a comprehensive book explaining those subjects? (I am trying to<br>> read all the material online, but books are easier to read and don't
<br>> require sitting in front of a computer to do so. Plus I can write in<br>> books :-). )<br><br>I've thought about writing extended tutorials on the relationship<br>between Haskell programming and category theory but there's a problem
<br>I run into. It's tempting to make the identifications:<br>types<->objects, Haskell function<->arrows, suitably polymorphic<br>functions<->natural transformations, and so on. But the fact is, this
<br>doesn't really work in the obvious way even though it seems like it<br>should at first (eg. Haskell functions aren't always total functions<br>in the mathematical sense and if you allow partial functions you can
<br>do weird stuff). So either:<br><br>(1) we need some technical work to patch up the differences (and<br>unfortunately I don't know what the patch-up is),<br>(2) we restrict ourselves to certain types of Haskell function for
<br>which the theory works or<br>(3) we deliberately leave things a little vague.<br><br>I usually tend to go for option (3), but that wouldn't be satisfactory<br>for an extended treatment.<br><br>Has anyone else given this subject much thought?
</blockquote><div><br>I consider myself to be distinctly in the target audience of a thorough treatment of CT & it's relationship to Haskell, so I'll throw out there that I think some superposition of options (2) and (3) would be the most satisfying. You can handwave a little bit, but knowing *where* the naive mappings between category theoretic constructs and Haskell's system breakdown would be very nice. Personally, one of the biggest things for me is not really having any intuition for what kind of category the Haskell type system lives in. I mean, it looks cartesian closed because you can do currying but what more to it is there than that?
<br></div><br></div><br>