Python-based monads essay part 2

[Marko Rauhamaa]

Chris Angelico <rosuav at gmail.com>:
> Okay. Now let's suppose that, instead of "73" in the first step, you
> have "ask the user for an integer". Are you allowed to eliminate this
> prompt, since the result of it cannot possibly affect anything? And if
> not, why not?

I would guess yes; that's how Python works as well:

    >>> 7 or input()
    7


However, if we think of the I/O interaction (aka *the process*) to be
the return value of a function, every bead in the I/O chain counts.

> After all, eliminating terms that have been multiplied by zero is one
> form of algebra.

I wonder if the word "algebra" brings anything to this discussion. It
doesn't make Haskell any more or less functional.

> If you consider that the world changes state as a result of asking the
> user for input, then you've just eliminated all notion of functional
> purity.

Not necessarily. Nothing changes the world. Rather you have different
worlds: the world of the past and the world of the future. The world of
the past is in the past of the world of the future:

    def print(world, text, cont):
        return cont(World(past=world, offset=text))

    def print_x_then_y(world, x, y, cont):
        return print(world, x, lambda world2: print(world2, y, cont))

> You have side effects, plain and simple, and you're using imperative
> code.

Technically, no. Thought-model-wise, yes.

Of course, recursive functions can simulate Turing machines and vice
versa. You can write purely functional code in purely imperative style.

My example above is purely functional as:

 * Every object is immutable.

 * The order of evaluation does not change the end result.

The end result is an ordered sequence of events. The topological order
is a causal order (you need the past world to construct the future
world), and causal order generates a temporal order.

Now, *if* the Haskell VM chooses to *realize* I/O events *as soon as* it
becomes aware of them, you get traditional, imperative side effects.


Marko