I agree with others who mentioned that viewing monads as simply providing a way to sequentialize things or to program imperatively is the wrong way to look at them. <snip> Yes, Lists are the classical example.
That said, the EFFICIENCY of monads is often poorly understood. To state the obvious, just because you program something in a monad doesn't make it efficient. In particular, a state monad does not guarantee that the state will actually be updated "in place". The monad only hides the state, and creates an OPPORTUNITY for it to be updated in place. But, for example, if you add an operation that returns the entire state as a value, then the "single-threadedness" property is in fact lost, and in-place update becomes as problematical as it always is. Well... I'm having *lots* of problems here. :-)
I've felt need to use State monads in two distinct situations: (A) Keep track of data, Example: - Genetic Algorithms how many crossovers, mutations, etc best (or average) individual fitness in each generation some schemata evolution etc... - Neural Networks Weights evolution Error evolution etc... (B) Acessing state There are some situation where you'll probably rather hide some implementation details in some state monad instead of passing around lots of values... Example: - Genetic Algorithms: Getting Rand. Numbers (instead of passing around all the StdGens you need) etc... And I've seen two distict aproaches. Using a State monad like one provided with GHC (1), or a state monad like the one defined in the paper "Moands for the Working Haskell Programmer" (2). In (1), I can see how I can take advantage of the monad and make updates in place using referencies. But then you'll have to either: - pass the referencies as a parameter to the functions where you use them (needless too say that this defeats the (my) main purpose of using a state monad which is in case A, keep track of data with minimal signature change ) - encapsulate all the functions in the monad. I don't really like this solution... you won't be even able to test the functions in the interpreter... - using implicit referencies (?) Haven't thought that much about this one yet In (2), I can't really see how to make updates in place... I still didn't figure out how to make my own State monad and use updates in place. What I did was - Define my state as some record (datatype with field labels) - Create functions to get and update state... This is doomed to fail! Even if I only want to update the state (like adding values to lists of values or incrementing some counters), I'll have to access that same state. So I'll have to make my own getStateField functions and updateStateField functions for every single field. Using datatypes with field labels makes it easy to define functions to get State fields (you get the would state then use the projection function)... but to update some field state it gets more complicated, if you got 6 counters, you'll have to write similar code 6 times... Damn, I seem to be waisting more time and writing more lines of code than if I was doing it in Pascal!! All just to keep track of some data, it is not even really 'part of the algorithm', I just want to evaluate how it is behaving.... Efficiency wise it seems pretty bad, no updates in place, and I'm expecting lots of stack overflows unless I take special care dealing with laziness. My problem with this is that I'm trying to do something trivial here..., forget about (B) (accessing state), I just want to keep track of data, any newbie can do that in the imperative world, and it seems like some pretty advanced stuff in here!! Programmers need to do this all the time, there should be some simple, well documented, way to do it. I don't want to be a monads expert to be able to do this kind of thing... (and I'm the kind of guy that wants to, eventually, become an monad expert... just not now... imagine how some other guy that has no interest in monads feels when he has the same problem.) IMO (and maybe I'm wrong... this is just the way I feel right now) either we are missing some simple aproach here, or at least we do not have at all the adequate documentation about it, at all. Another state issue, sometimes I have some values that I want to keep constant through the whole algorithm. Example: (some very simple NNs for instance) - learning rate - activation function - maximum number of steps - minimum error required So I'll just declare them as 'constants'. But what if I decide I want the user to be able to chose? Now I got two options: - pass them around as values to all the functions - And signatures get HUGE - just pass them to a higher level function that will encapsulate the functions that use them... which is ugly and complicates everything because you can't test the lower level functions in the interpreter. Am I missing something here or is this really the best you can do?
This is an issue that I and my student (Chih-Ping Chen) studied a few years ago, culminating in his PhD thesis and the paper:
Chih-Ping Chen and Paul Hudak, "Rolling Your Own Mutable ADT -- A Connection between Linear Types and Monads", Proceedings of 24th ACM Symposium on Principles of Programming Languages, ACM Press, 1997, pp. 54-66.
Interesting got to check it out... my main problem is that *I don't have the time* right now... sometimes you just want to get the job done. J.A.