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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > > 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