
From: Bulat Ziganshin
Hello Chad, Wednesday, November 30, 2005, 5:07:02 AM, you wrote:
SC> I've been reading some of the articles about comonads, and I thought SC> the idea of giving main the type OI () -> () was pretty interesting.
it looks interesting. what are you reading?
-- Best regards, Bulat mailto:bulatz@HotPOP.com
I'm reading the articles by Kieburtz and Uustalu linked from this page http://haskell.org/hawiki/CoMonadArticles On checking this again, I can't find the reference to the types I mentioned -- It may have just been the result of my reading the articles and letting the ideas simmer in my head, combined with a lack of rereading them before posting. I still need to read things through more carefully to be sure I understand it all correctly. In any case, here's the idea (still evolving, of course). There are safe functions of the form a -> IO b but not IO a -> b Dually, you should be able to write functions OI a -> b but not a -> OI b Now, suppose you want to read stdin, apply f to it, and print the result. The current standard is something like main = do s <- getContents print $ f s or main = getContents >>= (print . f) But it's simpler to write main = print . f . coGetContents where coGetContents :: OI () -> String f :: String -> a print :: a -> IO () Of course, changing the type of main alltogether is probably a bad idea, because it would break too much code. But maybe allowing constructions like this would be reasonable? Alternatively, there could be a nice way to write toMain :: (OI () -> IO ()) -> IO () My first thought is toMain f = f $ OI () but somehow this seems to easy, and I'm worried about the type safety. --------------------------------------------- Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory "Time flies like an arrow; fruit flies like a banana." -- Groucho Marx

See: http://haskell.org/pipermail/haskell-cafe/2003-January/003794.html
The OI comonad as previously envisioned breaks referential
transparency. I/O just doesn't seem to be something which one can
easily do comonadically, since once coeval/extract is applied, you're
back to plain values, and there's no imposition of sequencing.
- Cale
On 02/12/05, Scherrer, Chad
From: Bulat Ziganshin
Hello Chad, Wednesday, November 30, 2005, 5:07:02 AM, you wrote:
SC> I've been reading some of the articles about comonads, and I thought SC> the idea of giving main the type OI () -> () was pretty interesting.
it looks interesting. what are you reading?
-- Best regards, Bulat mailto:bulatz@HotPOP.com
I'm reading the articles by Kieburtz and Uustalu linked from this page http://haskell.org/hawiki/CoMonadArticles
On checking this again, I can't find the reference to the types I mentioned -- It may have just been the result of my reading the articles and letting the ideas simmer in my head, combined with a lack of rereading them before posting. I still need to read things through more carefully to be sure I understand it all correctly.
In any case, here's the idea (still evolving, of course). There are safe functions of the form a -> IO b but not IO a -> b
Dually, you should be able to write functions OI a -> b but not a -> OI b
Now, suppose you want to read stdin, apply f to it, and print the result. The current standard is something like
main = do s <- getContents print $ f s
or
main = getContents >>= (print . f)
But it's simpler to write
main = print . f . coGetContents
where coGetContents :: OI () -> String f :: String -> a print :: a -> IO ()
Of course, changing the type of main alltogether is probably a bad idea, because it would break too much code. But maybe allowing constructions like this would be reasonable?
Alternatively, there could be a nice way to write toMain :: (OI () -> IO ()) -> IO () My first thought is toMain f = f $ OI () but somehow this seems to easy, and I'm worried about the type safety. --------------------------------------------- Chad Scherrer Computational Mathematics Group Pacific Northwest National Laboratory
"Time flies like an arrow; fruit flies like a banana." -- Groucho Marx _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (2)
-
Cale Gibbard
-
Scherrer, Chad