On Wed, 2005-12-21 at 13:10 +0100, Udo Stenzel wrote: . . .
tutorial. Before that, IO should be restricted to the EVA principle ("Eingabe, Verarbeitung, Ausgabe" == "Input, Processing, Output"). It was a good principle in the 60s, and it still is. Unless you want to teach people to program as they would do in Basic, that is.
Don't forget that the pioneers of IPO (Input,Process,Output) quickly went to HIPO (Hierarchical IPO). My natural design style is top-down, functional decomposition, separation of concerns, all the good things. Many problems involve relatively complex mixtures of IO and processing, which I can capture fairly naturally with programs whose IO is distributed over various nodes low in a functional decomposition tree. It often feels like I'm turning a program inside-out to have the IO monad at the top with pure functional snippets called at various points in a "do" sequence. And if the only way to express my decomposition tree is with a tree of "imperative" code inside the IO monad, then I start to ask, "Why am I here? I can write this in Scheme or Ocaml". Since I'm a Haskell novice, I'm well aware that I may totally misunderstand the situation. However, I hadn't seen anything in tutorials that would lead me to think so. That said, one of the great effects of these recent threads is that they've alerted me to the fact that apparently the available tutorial information has expanded and been improved since last I looked. So I think I shall now go do some deep browsing; thanks for the links. -- Bill Wood PS: While looking over my post it occurred to me that the issue is at least as much methodological as it is linguistic. So I ask: Does Haskell stand far enough apart from other programming languages to warrant adapting standard methodological principles to it? Is there an identifiable "Haskell Way"? -- bw