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

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 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

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.