<div class="gmail_quote">On Thu, Mar 19, 2009 at 4:40 PM, Robert Raschke <span dir="ltr"><<a href="mailto:rtrlists@googlemail.com" target="_blank">rtrlists@googlemail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Hi,<br>
<br>
all this very interesting discussion about patterns and state carrying<br>
from one expression to the next makes me think a lot of state monads.<br>
<br>
I've never really delved into Haskell all too deeply (it's on my list<br>
of things to learn much more of), but would some of the objections and<br>
issues to do with numbered "state patterns" be addressed by something<br>
similar to state monads? I'm guessing that tuple patterns involving<br>
atoms as signifiers for results make this tricky, but maybe someone<br>
has thought about this in more detail?</blockquote><div><br>I haven't thought that hard about it, but it I do know a bit about Haskell.<br><br>Unlike Richard, I personally don't think that there is a very strong case for trying to add monads to Erlang, because Erlang is such a different language to Haskell.<br>

<br>Haskell is a language very much concerned about elegant semantics, but the upshot of that is that understanding efficiency issues become very hard. Monads were introduced to solve many of these problems. The ST monad allows you to manage large datastructures destructively, ensuring that they will be garbage collected - if computers had limitless CPU and RAM, it wouldn't be needed. The IO monad handles all I/O, non-determinism, concurrency; all the more messy, unpredictable areas of language behaviour are confined to the IO monad. So, in my opinion, monads were not really added into Haskell to make it more elegant. They were instead added to make it much more practical, without poisoning the elegance of the rest of the language.<br>

<br>But Erlang is totally different. It is already, at its heart, a really practical language. With a strict reduction order, managing datastructures efficiently is straighforward enough, and side-effecting is everywhere, so you're not trying to protect the rest of the language from "impure" features.<br>


<br>Much of the discussion about state handling was about syntax. But although there is a special imperative-like syntax for monadic programming in Haskell, that's not really the point of monads. The internal state variable *has* to be hidden for reasons related to Haskell's static type system, as is the case for I/O. (The Clean language, closely related to Haskell, uses a different type system, where there's actually a variable usually called "World" which is explicitly passed around when doing I/O)<br>

<br> So, in my opinion, if you were to add monads into Erlang, you would just get a monad-like syntax, without any other benefits. And it's debatable whether this is really an improvement - it's more concise, but at the same time, more is hidden from view.<br>

<br>kind regards,<br><br>malcolm<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Robby<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
<br>
______________________________________________________________________<br>
This email has been scanned by the MessageLabs Email Security System.<br>
For more information please visit <a href="http://www.messagelabs.com/email" target="_blank">http://www.messagelabs.com/email</a><br>
______________________________________________________________________<br>
</blockquote></div><br>