RE [Haskell-cafe] Monad Description For Imperative
lgreg.meredith at biosimilarity.com
Fri Aug 3 14:11:59 EDT 2007
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
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
I see that any type constructor TC :: * -> * is halfway to being a
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 ->
Now this is precisely the Haskell Functor class, so TC is the object
and fmap is the arrow part. You say that (>>= return . f) can be
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
>>= as "Sequentially composes two actions...".)
505 N 72nd St
Seattle, WA 98103
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe