:t main

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

:t main

Chad Scherrer-2
I've been reading some of the articles about comonads, and I thought the idea of giving main the type OI () -> () was pretty interesting. So I was wondering, would it be possible to allow the type of main to be inferred? It seems like
IO ()
OI () -> ()
OI () -> IO ()

all make sense (at least I think they do). One particularly nice side effect of this (pardon the pun) is that a good number of useful programs can be written as

getContentsW :: OI () -> a
doSomeStuff :: (Show b) => a -> b
print :: (Show b) => b -> IO ()
main = print . doSomeStuff . getContentsW

so much less understanding about monads et al is required to do some basic stuff. I think it would be much easier in this case to make the transition to Haskell.

Also, has anyone given any thought to syntactic sugar for comonads? Since arrows and monads share the (<-) symbol, it seems like a nice unification could be possible... Maybe (-<) alone could be used similarly?

Thanks,
Chad Scherrer
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: :t main

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
SC> thought the idea of giving main the type OI () -> () was pretty
SC> interesting.

it looks interesting. what are you reading?


--
Best regards,
 Bulat                            mailto:[hidden email]



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: :t main

Chad Scherrer-2
In reply to this post by Chad Scherrer-2


> From: Bulat Ziganshin <[hidden email]>
> 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:[hidden email]
>
>

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

Re: Re: :t main

Cale Gibbard
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 <[hidden email]> wrote:

>
>
> > From: Bulat Ziganshin <[hidden email]>
> > 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:[hidden email]
> >
> >
>
> 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
> [hidden email]
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Re: :t main

Chad Scherrer-2
In reply to this post by Chad Scherrer-2
> From: Cale Gibbard [mailto:[hidden email]]
> 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

Hmm, I hadn't seen that. The asymmetry is pretty frustrating in that
case.

After poking around a bit more, I (re)discovered some discussion of this
on Hawiki:
http://www.haskell.org/hawiki/CoMonad

After reading Dave Menendez's comments, I'm wondering...
If we consider
IO a = Realworld -> (Realworld, a)
then wouldn't we dually have something like
OI a = (Realworld, Realworld -> a)?

Could this be what screws things up? Right now it seems like OI is
acting like it has the same type as IO, with a different name.

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Re: :t main

David Menendez
Scherrer, Chad writes:

> > From: Cale Gibbard [mailto:[hidden email]]
> > 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
>
> Hmm, I hadn't seen that. The asymmetry is pretty frustrating in that
> case.
>
> After poking around a bit more, I (re)discovered some discussion of
> this on Hawiki:
> http://www.haskell.org/hawiki/CoMonad
>
> After reading Dave Menendez's comments, I'm wondering...
> If we consider
> IO a = Realworld -> (Realworld, a)
> then wouldn't we dually have something like
> OI a = (Realworld, Realworld -> a)?
>
> Could this be what screws things up? Right now it seems like OI is
> acting like it has the same type as IO, with a different name.

Aside from the product comonad and the exponent (reader) monad, I don't
think we'll find much overlap between monad and comonad functionality.
It's been said that monads describe effects that propagate outwards,
whereas comonads describe effects that propagate inwards.

My guess is that comonadic IO would look more like dataflow programming.
--
David Menendez <[hidden email]> | "In this house, we obey the laws
<http://www.eyrie.org/~zednenem>      |        of thermodynamics!"
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Re: :t main

Simon Peyton Jones
In reply to this post by Chad Scherrer-2
I've not been following this thread, but I wanted to check: you do know
about Tarmo Uustalu's stuff about comonads, don't you?

http://www.cs.helsinki.fi/u/ekarttun/comonad/  summarises (link to "The
essence of dataflow programming" at the bottom)

Simon

| -----Original Message-----
| From: [hidden email]
[mailto:[hidden email]] On Behalf Of
| David Menendez
| Sent: 06 December 2005 07:13
| To: Scherrer, Chad
| Cc: [hidden email]
| Subject: RE: [Haskell-cafe] Re: :t main
|
| Scherrer, Chad writes:
|
| > > From: Cale Gibbard [mailto:[hidden email]]
| > > 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
| >
| > Hmm, I hadn't seen that. The asymmetry is pretty frustrating in that
| > case.
| >
| > After poking around a bit more, I (re)discovered some discussion of
| > this on Hawiki:
| > http://www.haskell.org/hawiki/CoMonad
| >
| > After reading Dave Menendez's comments, I'm wondering...
| > If we consider
| > IO a = Realworld -> (Realworld, a)
| > then wouldn't we dually have something like
| > OI a = (Realworld, Realworld -> a)?
| >
| > Could this be what screws things up? Right now it seems like OI is
| > acting like it has the same type as IO, with a different name.
|
| Aside from the product comonad and the exponent (reader) monad, I
don't
| think we'll find much overlap between monad and comonad functionality.
| It's been said that monads describe effects that propagate outwards,
| whereas comonads describe effects that propagate inwards.
|
| My guess is that comonadic IO would look more like dataflow
programming.
| --
| David Menendez <[hidden email]> | "In this house, we obey the
laws
| <http://www.eyrie.org/~zednenem>      |        of thermodynamics!"
| _______________________________________________
| Haskell-Cafe mailing list
| [hidden email]
| http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Re: :t main

Chad Scherrer-2
In reply to this post by Chad Scherrer-2

> From: Simon Peyton-Jones [mailto:[hidden email]]

>
> I've not been following this thread, but I wanted to check:
> you do know about Tarmo Uustalu's stuff about comonads, don't you?
>
> http://www.cs.helsinki.fi/u/ekarttun/comonad/  summarises
> (link to "The essence of dataflow programming" at the bottom)
>
> Simon
>

Thanks, Simon. I've seen it, but I haven't fully digested it yet.
Dataflow programming is new to me, and it's not immediately obvious how
it ties in with IO in general. I'll take another look, though.

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
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|

RE: Re: :t main

David Menendez
In reply to this post by Simon Peyton Jones
I wrote:
> | My guess is that comonadic IO would look more like dataflow
> | programming.

Simon Peyton-Jones writes:

> I've not been following this thread, but I wanted to check: you do
> know about Tarmo Uustalu's stuff about comonads, don't you?
>
> http://www.cs.helsinki.fi/u/ekarttun/comonad/  summarises (link to
> "The essence of dataflow programming" at the bottom)

You caught me. That paper was the reason I thought comonadic IO might
resemble dataflow programming. I should have provided a link, but I was
lazy.

I also recommend "Comonadic functional attribute evaluation"[1] and "The
dual of substitution is redecoration"[2], which have nothing to do with
IO but do describe some applications of comonads.

[1] <http://cs.ioc.ee/~tarmo/papers/tfp05-book.pdf>
[2] <http://cs.ioc.ee/~tarmo/papers/sfp01-book.ps.gz>
--
David Menendez <[hidden email]> | "In this house, we obey the laws
<http://www.eyrie.org/~zednenem>      |        of thermodynamics!"
_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe