On Tue, May 03, 2005 at 12:38:25AM -0400, Daniel Carrera wrote:
So, I figure that to do these tasks you heed that "do ... <-" work around. But that kills the whole point of using FP in the first place, right?
In my experience, the amount of IO code in an average Haskell program is from 1% to 20%, even in applications which have to do a fair amount of interaction with the outside world (networking, CGI, system utils). It may be more in GUI applications - I don't have much experience in this area. But I expect that the most interesting GUI applications aren't made for the sake of GUI, but to solve some algorithmically complicated problems, and solutions to such problems are often most easily implemented purely. I can't strictly define what "IO code" means for me, because IO and purely functional code are often so mixed in Haskell programs. This is also a great strength of Haskell - pure functions are very convenient as a glue for imperative actions. Haskell's IO is not just a mimicry of traditional imperative languages, it's an EDSL (embedded domain specific language) for doing IO. Because it's embedded it benefits from all the other features of Haskell, like first-class functions, higher-order functions, lexical closures, pattern matching, etc, etc. In fact, IO actions of a Haskell program are first computed, purely. You can build imperative programs on-the-fly, pass them to and from functions, store them in data structures, etc, etc. You can build your own abstractions, for example looping constructs. One nice difference between Haskell's IO actions and statements of imperative languages like C is that every IO action can yield a value. For example, a block of C code enclosed in braces cannot return a value. You might wan't to put code in such block to reduce the scope of some helper variables. In C if you want to "return" a value from such block you have to use assignment (in a way that detaches variable's declaration from its assignment) or move this code to a function. In Haskell you can: x <- do { ... ; ... ; return (some expression) } ...
So, I'm tempted to conclude that FP is only applicable to situations where user interaction is a small part of the program.
If you mean that Haskell is rarely applicable, I disagree. Best regards Tomasz