[Haskell-cafe] Martin Odersky on "What's wrong with Monads"

[Donn Cave]

To be fair, while it's great that Functor et al. are available to
help solve problems like that with a Tree data structure, in the
present context it mostly shows that a trivial example was used
to illustrate the problem.  Unless I'm missing how this generic
fold functionality solves the more general problem.

Quoth Alberto G. Corona,

> ... There is no such problem in imperative languages, which work
> ever in an hardwired IO monad.

Or to look at it from the other direction, the problem with Haskell
is that it allows the programmer to write non-IO functions.  To the
extent that's a real problem, the solution would obviously be to
exercise some restraint with the pure code and write more in the
IO monad.  If you will humor me, we understand that this code is
equally satisfactory from a mathematical perspective and there's
no crime in it.  But does it help with the `flags problem?'

Suppose that functions f and g both have IO types;  f calls g,
and g has optional behavior depending on some IO value computed
previously, the flag.  The way I understand it, I can accomplish
this without passing the flag around:  with an IORef.

What's less clear to me is whether Haskell really supports the module
level accessible IORef value I need.  Also known as "top level mutable
state."  Is the NOINLINE pragma I've been using with GHC, really a
sound and reliable practice that we're reasonably confident will be
supported by other compilers?

It feels to me like I'm pulling a weird trick, to do something that's
trivial in other programming languages.  Maybe that's part of the
problem, that imperative programming receives something a little short
of full support in Haskell, inasmuch as basic features like top level
mutable state require relatively arcane incantations.

	Donn