Am Donnerstag, 22. Dezember 2005 03:32 schrieb Gregory Woodhouse: > [...]
> If this analogy is at all valid, then I wonder if the IO monad, at > least, doesn't represent something of a blurring of the traditional > distinction between applications and operating system functionality. An application can modify local state, e.g., a C variable. Purely functional code cannot do this. > Incidentally, devices do not necessarily correspond to hardware and > you can write drivers to do all sorts of interesting things if you > are so inclined -- just as monads are not limited in their use to I/O. The IO monad is not just about I/O but also about modifiable variables. Most other monads only deal with purely functional stuff. For example, a list has nothing to do with modifiable variables and I/O at all. > > We have a "evaluation machine" and a "execution machine". The former > > evaluates expressions, the latter executes I/O actions. > > This is where I'm a bit fuzzy. "Actions" make think of something like > a finite automaton, where the action would be (possibly) consuming an > input token and changing state. "Actions" makes me think of things like I/O and modifying variables in contrast to calculations which don't really "act". Of course, an I/O action, for example, modifies a state, namely the state of the outside world. > > When the program is started, the execution machine wants to execute the > > actions from the "main to do list". In order to be able to do so, it asks > > the evaluation machine to start evaluating main. For each entry on the to > > do list, main is evaluated as far as it's necessary to provide the > > execution machine with the entry. Of course, evaluating main may result > > in evaluating other expressions. > > I imagine this is somewhat analogous to a C statement like > > c = getchar(); > > Evaluation is "blocked" (and the process becomes not runnable) until > such a time as getchar() returns a value. If there is no buffered > input, a system call will be required, and control will pass to the > driver for the appropriate device. When control returns to the > calling process it can, of course, go on until it again > (transparently) blocks, waiting for input or other actions. I meant it the other way round. The execution machine does something like the following: while (actionsRemaining()) { nextAction = getNextAction(); executeAction(nextAction); } getNextAction() will force the evaluation machine to evaluate as much of main as is needed to provide the execution machine with the next action. > > The point is that the evaluation machine does never execute any I/O > > actions while the execution machine is unable to do any evaluation but > > needs to be feeded by the evaluation machine. > > Is this a reasonable analogy? I think so. :-) > [...] Best wishes, Wolfgang _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe