Hello, If I understand what you're saying, it seems that an intuitive view of OI would be : passing a token allowing to do IO operations. We pass the token to the main function. After an operation we give the token to next. It's unsafe to crete a new token.

From this, I think the safety become intuitive.

Cheers, N. On Tue, 31 Dec 2002, Ashley Yakeley wrote:

In article , peter@premise.demon.co.uk (Peter G. Hancock) wrote:

...

Frustratingly, I can't seem to grasp the intuition. I'm aware that the state-monad s->(s,a) has a dual state-in-context comonad (s,s->a). How does the side-effect manifest itself? The (ineffective) hints the authors give revolve around the idea that side-effects "derive" from the context of a program. Any other hints? ... I can't make the slightest sense of Kieburtz's OI co-monad, with commands like coGetChar :: OI Handle -> Char.

I've been wondering this myself. I always think of an object of type "IO a" as "an imperative action that returns an a", but I have no similar understanding for "OI a". But I think OI programs have the same restrictions against unsafety as IO programs.

class Comonad w where (=>>) :: w a -> (w a -> b) -> w b (.>>) :: w a -> b -> w b coeval :: w a -> a

instance Comonad OI where etc.

The first thing I notice is that you can't create objects of type "OI a". I think your main program would be:

main :: OI () -> ()

Equivalent to "unsafePerformIO" would be:

unsafeOI :: OI ()

unsafeMakeOI :: a -> OI a unsafeMakeOI a = unsafeOI .>> a

The other thing I notice is that functions of type "(Comonad w) => w a -> b" seem to be equivalent to functions of type "(Comonad w) => w () -> a -> b". For instance:

coGetChar :: OI Handle -> Char coGetChar' :: OI () -> Handle -> Char

coGetChar' oi h = coGetChar (oi .>> h)

coGetChar oih = coGetChar' (oih .>> ()) (coeval oih)

You certainly can't pull anything like this with monads. This would suggest comonads don't need to by type-constructors at all. But I'm not sure if it's correct. Opinions?

-- Ashley Yakeley, Seattle WA

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

In article <20030102225641.GA24187@smtp.alicorna.com>, Andrew J Bromage wrote:

comain :: OI a -> () comain w = coeval (w .>> show (a,b) =>> stdPutStrLn) where a = coeval (w .>> () =>> stdGetChar) b = coeval (w .>> () =>> stdGetChar)

Even though a and b are identical, they return different values. I see two possibilities: Either my intuition is way off, or the OI comonad breaks referential transparency.

So is Kieburtz smoking crack, or are we writing OI-style programs incorrectly? One possibility is that comonads are useful for some things, but not for doing IO actions safely. -- Ashley Yakeley, Seattle WA

In article <20030103042118.GA26720@smtp.alicorna.com>, Andrew J Bromage wrote:

On Thu, Jan 02, 2003 at 08:08:20PM -0800, Ashley Yakeley wrote:

...

So is Kieburtz smoking crack, or are we writing OI-style programs incorrectly?

I mailed him the example and asked. (I phrased the question a bit differently, though.)

Did you ever get a reply? It's been three months... -- Ashley Yakeley, Seattle WA