Right. I did not think I was stating anything grand here. I was simply pointing out that "imperative" mixed with "mutable" state is not something that is hard for users to grasp. Especially when limited in scope to single threads of action. The hard part comes in making sure this "type checks." That is, if you had it dependently typed such that you could not "add_into( &pot, contents );" until after you had "add_into( &pot, waterfactory() );" than you could conceivably catch more bugs.
The trick, to me, is that the "type" of "pot" is not fixed in this. Since I consider the "type" to be dependent on its state. I know this can be done with generic and higher order programming, but usually not with the same reference. That is, each call would create a new reference to pot such that the next one fed off of that. Thing is, that doesn't read well. (I mean, it does for toy examples, but doesn't for long ones.)
I feel compelled to give kudos for by far the most readable of the "as program" directions here. Don't get me wrong, I can read most of the other examples, but this is the only one that really reads more true to how you would describe the process to someone and really underscores where I think a lot of the functional advocacy falls flat.
The trick, to me, is that the "type" of "pot" is not fixed in this. Since I consider the "type" to be dependent on its state. I know this can be done with generic and higher order programming, but usually not with the same reference. That is, each call would create a new reference to pot such that the next one fed off of that. Thing is, that doesn't read well. (I mean, it does for toy examples, but doesn't for long ones.)
Make sense?