monad vs. self-call?

in Erlang i believe one gets statefulness from pure functions by
having them pass new values in to calls to themselves for ever. is
that a useful thing to do in Haskell?

(basically i'm trying to understand various ways to deal with
statefulness; i've been looking at ioRef, and am now trying to learn
about the State monad, and wonder what other options there might be.)

thanks.

raould <raould@gmail.com> wrote:
> in Erlang i believe one gets statefulness from pure functions by
> having them pass new values in to calls to themselves for ever. is
> that a useful thing to do in Haskell?

Yes, if the state has managable size. Functions like "iterate" are
quite useful for that. If the state gets to big, the State monad
is better to "hide the plumbing" (after all, it's just a formalized
way to thread state around from pure functions to "themselves").

Of course, in Erlang you can distribute state among various process,
turning each process into an "object", so Erlang has a natural way to
split up state into small chunks (which is what OOP is about in the
first place, at least IMHO). Haskell can't do that easily, or at least
I haven't seen an idiom which would make that approach look natural.

> (basically i'm trying to understand various ways to deal with
> statefulness; i've been looking at ioRef, and am now trying to learn
> about the State monad, and wonder what other options there might be.)

I think these three are the main options. If state is simple, pass it
around. If it gets complex, hide it in a State monad or a derivate.
If you're doing IO anyway, use IORefs.

- Dirk

Ertugrul Söylemez <es@ertes.de> wrote:
> Dirk Thierbach <dthierbach@usenet.arcornews.de> wrote:

>> Of course, in Erlang you can distribute state among various process,
>> turning each process into an "object", so Erlang has a natural way to
>> split up state into small chunks (which is what OOP is about in the
>> first place, at least IMHO). Haskell can't do that easily, or at least
>> I haven't seen an idiom which would make that approach look natural.

> Isn't this a good use case for StateT over IO?

Why should it?

> mainThread :: StateT AppState IO ()
> mainThread = do
> doSomething1
> s <- get
> liftIO $ forkIO $ evalStateT subThread (partOf s)
> doSomething2
>
> subThread :: StateT PartOfAppState IO ()
> subThread = doSomething3

> Maybe I'm misunderstanding you.

At least I don't understand what you're aiming at :-) Of course
one can imitate Erlang processes, but in Erlang that is natural and
the VM is optimized for it. In Haskell, that isn't the case.

- Dirk

Ertugrul Söylemez <es@ertes.de> wrote:
> On the other hand, many features and concepts that are primitive in
> other languages (i.e. language or RTS features) are library
> functionalities in Haskell, so in fact you could say about almost
> everything that it's just an imitation of what is a primitive feature in
> another language.

Yes. Most programming languages are Turing complete, so all those
languages can emulate each other.

> Considering this, I don't see any problems with imitating concepts from
> other languages, as long as the imitation is solid and beautiful. In
> Haskell, this is usually the case.

The key word is *natural*. In Erlang, it's natural to have lots of
little processes that represent a very fine grained partitioning of
the whole state. One can imitate that in Haskell, but (at least to me)
it wouldn't feel natural -- I'd rather use a low number of threads
that in turn partition their state in the ways mentioned before.

So while there's indeed no problem simulating either approach in the
other language, it's just not something I would do. And there may be
performance penalties (because the Erlang VM is heavily optimized for
*lots* of distributed processes), as well.

- Dirk

> Explicit passing is, of course, a useful thing, if you want to be that
> verbose. *Personally I consider it rather annoying, though, so I prefer
> using State monads.

> Another option is to make use of concurrency, but that works only in the
> IO monad, and it should be used carefully, not to be too imperative.

thanks (to you and others) for the help, it really is starting to sink
in to my brain, even if it requires repetition (http://tinyurl.com/
65563q) :-}