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