On 24 June 2012 18:46, Alexander Solla <alex.solla@gmail.com> wrote:

I sort of see where you're coming from.  But I'm having a hard time seeing how this "complaint" would work with respect to Maybe and the other pure monads.  In other words, I suspect the problem you're describing is particular to IO and IO-like monads.
 
Yes this problem is specific to IO-based functions. If you didn't know anything about monads yet would have written a Maybe/Either function then the types are identical to the monadic formulation, and the monadic framework in this case is just helping you to structure everything. Unless this structucture is obscuring or confusing matters (and I don't see it) its difficult to imagine any objection here.
 
I don't know SML.  How is our list "monadic" and theirs not?  In particular, how is Haskell "forcing" the reification while SML does not?

In SML you can put side-effecting computaions in 'pure' functions -- functions whose type doesn't reveal that there are side effects. In Haskell terms, every function is actually in the IO monad -- or every function is given carte blanche to use unsafePerformIO depending upon how you look at it. In semantic terms it is really a case of the former; from a programming perspecive it is more like the latter; Standard ML is strict and I am pretty sure this is only practical in a strict language. It is (IMHO) deeply horrible, and possibly justifiable before monadic I/O was invented (but not for me).

I am not advocating doing this (at all) but using it to illustrate a point. In standard ML you can start doing effect-based things inside a function without having to alter its type and they type of everything that uses it, and so on.

Chris