[Haskell-cafe] Functions with side-effects?

[Wolfgang Jeltsch]

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