Tracy R Reed wrote:
Ah, very interesting. I think I get it. Seems relatively simple.
Yeah. The explanation I saw is that the process turns into something like
(O1, 'C') <- read (O0)
(O2, 'A') <- read (O1)
(O3, 'T') <- read (O2)
and there's really only one order you can evaluate the "read" calls in,
and it happens to spell "CAT". The O variable holds the monad. It's
just a way of forcing evaluation to go in a particular order.
So why do all of the other explanations I have read talk about encapsulating
nuclear waste
Because the type system prevents you from assigning to the monad using
anything other than (in this case) the "read" function. The O1, O2, O3
are encapsulated to the point where you can't examine or change them,
because there's no operation that accepts a monad (of that type) and
returns anything other than a result that includes a monad (of that
type). The "nuclear waste" is the side-effects that you don't have any
of in a functional language.
In truth, you can look at something like Haskell (theoretically) as
computing a giant formula that is valid for any input and tells you what
the associated output is, before it ever sees any of the input. Then,
when you're all done evaluating that function, you give it a specific
input and the result is a specific output.
It always seemed to me that would be a great model for a transactional
system, like a web app that takes HTTP POST as input and results in a
list of SQL statements and HTML output to be returned.
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
