RE [Haskell-cafe] Monad Description For Imperative

[Greg Meredith]

Haskellians,

i am delighted to see vigorous exchange that actually resulted in change of
positions. i confess i was going to give up, but glad others stepped into
the breach. This is yet another indication of what an unusual community this
is.

Best wishes,

--greg

Date: Fri, 3 Aug 2007 13:43:32 +1200
From: ok <ok at cs.otago.ac.nz>
Subject: Re: RE [Haskell-cafe] Monad Description For Imperative
To: haskell-cafe Cafe <haskell-cafe at haskell.org>
Message-ID: <8575BD1C-2113-4D48-A3D4-BDFF41238BB9 at cs.otago.ac.nz>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

I asked "How is IO a functor"?

On 3 Aug 2007, at 11:50 am, Dan Piponi wrote:
> IO is a fully paid up Monad in the categorical sense. The category is
> the category whose objects are types and whose arrows are functions
> between those types. IO is a functor. The object a maps to IO a. An
> arrow f::a->b maps to (>>= return . f)::IO a -> IO b and that can be
> used to make IO an instance of Functor. The natural transforms eta and
> mu are called return and join.


Please go over this again, but slowly this time.
You have convinced me, but I'd like to understand the details a little
better.

I see that any type constructor TC :: * -> * is halfway to being a
functor
on this category of types.  It acts on the objects in the obvious way,
so the next step is to see about the arrows.

   If f :: a -> b then we want TC f :: TC a -> TC b

such that TC (f . g) = TC f . TC g and TC (id::a->a) = id :: TC a ->
TC a

Now this is precisely the Haskell Functor class, so TC is the object
part
and fmap is the arrow part.  You say that (>>= return . f) can be
used to
make [a Monad] an instance of Functor.  Try it... by golly it's true.
I see:  fmap f = (>>= return . f).

So why *aren't* Monads already set up using the type class machinery
to always *be* Functors in Haskell?  Isn't it bound to confuse people
if monads are functors but Monads are not Functors?

This is especially puzzling because Maybe, [], and IO already *are*
Functors, but the way this is done makes it look accidental, not like
the fundamental property of Monads it apparently is.

(By the way, I note that the on-line documentation for Control.Monad
glosses
 >>= as "Sequentially composes two actions...".)


-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
505 N 72nd St
Seattle, WA 98103

+1 206.650.3740

http://biosimilarity.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20070803/8ce629ce/attachment-0001.htm