Python-based monads essay part 2

[Chris Angelico]

On Tue, Oct 18, 2016 at 8:56 PM, Rustom Mody <rustompmody at gmail.com> wrote:
> One thing probably is correct in what you are saying (if you are saying!):
> The IO monad cannot be programmed at the vanilla user/programmer level but must
> be hardwired into the system (for an FPL of course; for python its all demo anyway)

That's about right. (And yeah, I'm fine with the Python demos being a
bit forced - it's a lot easier than all of us trying to learn Haskell
syntax. Though I do appreciate the examples of the Haskell
equivalents, where we get to see how clean it looks in actual usage.)

So what that really means is:

1) In actual Haskell code (as opposed to standard library code), there
are certain restrictions, including that your functions must be pure.
2) Standard library code is allowed to play fast and loose with the rules.
3) This makes Haskell actually useful, instead of being an interesting
research project.

For comparison, Python has similar rules:

1) In actual Python code, there are certain restrictions, including
that your object references must be perfectly maintained.
2) Standard library code is allowed to play fast and loose (eg making
weakrefs that don't count as actual references, or releasing the GIL
while doing heavy computation, etc).
3) This makes Python actually perform fast, instead of being a pure
and naive byte-code interpreter.

In each case, I absolutely agree with the third point. There is
nothing wrong with sacrificing a bit of purity in order to gain a ton
of practicality, especially if you can bury the sacrifice away in some
deep corner of the language. However, it is patently false to claim
that all of CPython could be implemented using equivalent Python code;
for instance, you would have no way of ever creating the top-of-tree
loop wherein 'object' is an instance of 'type', and 'type' is a
subclass of 'object'. In the same way, I think, it is patently false
to claim that Haskell is purely functional - but the I/O monads are a
crucial feature in making the language useful.

Just please, stop trying to claim that it's purely functional. It
isn't. It's imperative with functional paint.

(Unless I'm flat wrong in my analysis, of course, in which case I'm
happy to be corrected in my understanding.)

ChrisA