[Haskell-cafe] Do real programs need IO? (was IO is a bad example for Monads)

[Daniel Fischer]

Just darcs got TV and read the sources.
Awesome stuff!

But what do I find in Interface.TV.IO ?

-- | 'Input' version of 'getContents'
contentsIn :: Input IO String
contentsIn = iPrim getContents

-- | 'Input' version of 'readFile'
fileIn :: FilePath -> Input IO String
fileIn name = iPrim (readFile name)

-- | 'Output' version of 'writeFile'
fileOut :: FilePath -> Output IO OI String
fileOut name = oPrim (Flip (writeFile name))

> If by "programme", you mean the code I write, then I'm happy to deny that
> my programme has to do these things.  

If you're saying you have a great library which takes care of IO chores, among 
other things, enforces (or at least strongly supports) separation of 
algorithm and IO, so that basically you have written the IO-part of your 
programmes once and for all, I won't deny that.
If you're saying your programmes don't use the IO monad to interface with the 
external world, I disagree.
If you consider your library to be part of the stateful RTS, I conclude that 
we have different ideas about the meaning of RTS.

Anyway, thanks for acquainting me with TV, it is a really cool library.

Cheers,
Daniel

Am Sonntag, 9. Dezember 2007 20:26 schrieb Conal Elliott:
> On Dec 9, 2007 10:07 AM, Daniel Fischer <daniel.is.fischer at web.de> wrote:
> > Interactive programmes without using IO? Cool :)
>
> And how!
>
> > I think you misunderstood Lennart.
>
> Thanks for checking.  In this case, I think I understood Lennart fine and
> that he was saying what you're saying.
>
> > Would you deny that any useful programme has to do at least some of the
>
> following:
> > -accept programme arguments at invocation
> > -get input, be it from a keyboard, mouse, reading files, pipes...
> > -output a result or state info, to the monitor, a file, a pipe...
>
>    ===
>
> If by "programme", you mean the code I write, then I'm happy to deny that
> my programme has to do these things.  Examples below.  If you include a
> stateful RTS, then no I don't deny it.
>

> Explicit imperative programming is just one way to deal with input &
> output, not the only way.  As proof, see FRP, Pan, or TV programs, which
> contain uses of none of these functions.  (Nor could they, as these
> libraries are functional, having IO-free types and semantics.)  Moreover,
> use of imperative programming sacrifices some of the semantic simplicity &
> composability that makes FP so appealing.  That's why I'd like to see this
> belief in its necessity dispelled.
>
> That said, I don't think the existing functional (non-IO) approaches to
> interaction are quite there yet with the flexibility of imperative
> programming.  It will take more work to get them there, and that work is
> mostly likely to be pursued by people who doubt the necessity of IO for
> writing "real programs".  In that sense, Lennart's and your statements are
> self-fulfilling prophechies, as are mine.
>
> BTW, if you haven't seen it already, please check out
> http://haskell.org/haskellwiki/TV .  The TV (tangible values) approach
> includes a simple algebra of interfaces (input/output) and keeps separable
> from the core computation.  The separability allows the interface parts to
> be composed in parallel with the core part.  For instance, when two
> function-valued TVs are composed, the interfaces are peeled off, so that
> the core functions can be composed directly.  The output half of one
> interface and the matching input half of the other are discarded.  The
> remaining input and output halves are recombined into a new interface,
> which is used as the interface of the composed TV.  The core interface
> algebra can be used for text stream i/o, GUIs, and many other possible
> styles of information passing.
>
> I mention TV, because it's an example of combining the purity &
> composability I love about FP with the usability a "real" app.  For more
> about this combination, please see my Google tech talk "Tangible Functional
> Programming: a modern marriage of usability and composability" (
> http://conal-elliott.blogspot.com/2007/11/tangible-functional-programming-m
>odern.html). That talk focus on end-user composability, but the essential
> points apply as well to explicit programming.  As I mentioned before, TV
> (a) is currently less flexible than imperative/IO programming, and (b) has
> the composability, guaranteed safety, and amenability to reasoning of pure
> functional programming.
>
>
> Cheers,  - Conal
>
> Am Sonntag, 9. Dezember 2007 18:31 schrieb Conal Elliott:
> > > > IO is important because you can't write any real program without
> > > > using it.
> > >
> > > Ouch!  I get awfully discouraged when I read statements like this one.
> >
> >  The
> >
> > > more people who believe it, the more true it becomes.  If you want to
> > > do functional programming, instead of imperative programming in a
> >
> > functional
> >
> > > language, you can.  For instance, write real, interactive programs in
> >
> > FRP,
> >
> > > phooey, or TV.  And if you do, you'll get semantic simplicity, powerful
> >
> > &
> >
> > > simpler reasoning, safety and composability.
> > >
> > >   - Conal
> > >
>  > > On Dec 8, 2007 1:26 AM, Lennart Augustsson <lennart at augustsson.net>
>
> wrote:
> > > [...]
> > >
> > > IO is important because you can't write any real program without using
>
> it.
>
> > > So why not teach enough of it to get people off the ground straight
>
> away?
>
> > > People who hang around long enough to do some more Haskell programming
> > > will run into the other monads sooner or later.  But IO is an
>
> unavoidable step to
>
> > > writing Haskell programs.