Creighton Hogg wrote:
On 3/27/07, *Dan Piponi* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
On 3/27/07, [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> Given the amount of material posted at haskell.org
<http://haskell.org> and elsewhere
> explaining IO, monads and functors, has anyone considered publishing
> a comprehensive book explaining those subjects? (I am trying to
> read all the material online, but books are easier to read and don't
> require sitting in front of a computer to do so. Plus I can write in
> books :-). )
I've thought about writing extended tutorials on the relationship
between Haskell programming and category theory but there's a problem
I run into. It's tempting to make the identifications:
types<->objects, Haskell function<->arrows, suitably polymorphic
functions<->natural transformations, and so on. But the fact is, this
doesn't really work in the obvious way even though it seems like it
should at first (eg. Haskell functions aren't always total functions
in the mathematical sense and if you allow partial functions you can
do weird stuff). So either:
(1) we need some technical work to patch up the differences (and
unfortunately I don't know what the patch-up is),
(2) we restrict ourselves to certain types of Haskell function for
which the theory works or
(3) we deliberately leave things a little vague.
I usually tend to go for option (3), but that wouldn't be satisfactory
for an extended treatment.
Has anyone else given this subject much thought?
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?
Actually it isn't Cartesian Closed (monoidally closed though should work).
But, I more or less agree. Either just ignore it (3), or something somewhere
between (2) and (3) would probably be best. The kind of people that are going
to care enough about the mismatches probably already know to be wary, but make
sure you make -some- comment to the appropriate effect. Most of the time you
are just going for intuition and (either way) precision in this aspect is
irrelevant.
A request: If you do write this, please show the CT being -used- for something
and not just mapped to/from Haskell.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
