I think your real point is that some things we still haven't figured out how to express functionally. Right? I would certainly agree with that part. Perhaps you exaggerating when you wrote "IO is important because you can't write any real program without using it." Cheers, - Conal On Dec 9, 2007 12:14 PM, Lennart Augustsson wrote:

Conal,

I think TV etc. is fantastic stuff, but that mean that we cannot, say, invoke an external program in Haskell until someone has figured out a composable library for this? I sincerely hope someone will, but the only way we have right now is the ugly IO monad.

-- Lennart

On Dec 9, 2007 7:26 PM, Conal Elliott wrote:

...

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.

...

I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early.

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-mo...). 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@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.

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

Thanks for the clarification.

AFAIK, the only way to get input and produce output is via the IO monad

Now you know something different, don't you? FRP, Pan, TV. Also Grapefruit, functional forms, and others I'm not thinking of or don't know about. As for your example, mixing the IO with the functional, as you have interferes with composing the result. I can think of two alternatives. One is to move reading & printing from the definition to the uses, as with Unix stream filters. Still convenient, and much more flexible. Of course, Unix programs were written in C and so use explicit I/O instead of lazy functional streams. (Though Doug McIlroy, who invented Unix pipes, knew that pipes were equivalent to coroutines and to lazy evaluation. See my "modern marriage" talk (the video I mentioned) for more about Unix and TV.) A second alternative is to use TV to explicitly capture the interface (I/O), which could look like this: coolTV :: TV (String -> String) coolTV = tv (olambda (fileIn "Data.txt") defaultOut) performAwfullyCoolFunctionalStuff where tv :: Output src snk a -> a -> TV src snk a The type parameters src & snk are for various interface styles. Then coolTV can then be used on *either* side of a TV-style pipe, resulting in the removal of the reading or writing half. And yes, there are *some* uses of IO for which I'd be hard pressed at this point to offer you an alternative. Which is a far cry from IO being necessary for all "real" programs, even today. Given this state of affairs, I'd prefer the Haskell community to point newbies away from IO and toward purely functional programming for things like UIs and graphics and help them change their way of thinking. Let's also admit that we haven't yet figured out how to apply our functional paradigm as flexibly or broadly as we'd like, and so meanwhile we have thi monadic IO trick that let's them write nicely factored imperative code that can call into the functional pieces. Regards, - Conal On Dec 9, 2007 12:54 PM, Daniel Fischer wrote:

Am Sonntag, 9. Dezember 2007 21:29 schrieb Conal Elliott:

...

I think your real point is that some things we still haven't figured out how to express functionally. Right?

That's my point, at least. Currently, AFAIK, the only way to get input and produce output is via the IO monad, so it is de facto necessary for all 'real' programmes, it need not remain so (though I cannot imagine how to functionally express 'readFile "Data.txt" >>= print . performAwfullyCoolFunctionalStuff' - surprise me :). Read "IO is important" as a description of current affairs, not as a claim of the inherent grandeur of it.

Cheers, Daniel

...

I would certainly agree with that part. Perhaps you exaggerating when you wrote "IO is important because you can't write any real program without using it."

Cheers, - Conal

Am Montag, 10. Dezember 2007 07:05 schrieb Maurí­cio:

...

...

(...) 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...

===

As long as we use current interfaces, no one would deny it.

I thought Conal did, but it turned out that he just had a wider concept of RTS than I.

But after reading some stuff about Epigram language, I wonder if those ideas could not be used to write a better interface to computers. Then, all those tasks would be handled by your interface plug-ins, not by programs.

Really, we need to do all of that today. But I believe reading from keyboard, files etc. should not be part of programs we write daily, just a task for a basic interface to which our programs should be linked.

Agreed, but until then, we need IO to write 'real' programmes. We can already encapsulate it somewhat using libs like TV, as I learnt yesterday, but even more encapsulation wouldn't be bad.

Best, Maurício

Cheers, Daniel