<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Perhaps this might help:<br>
<br>
I wrote a kind of logger monad that inserted messages with a
context.<br>
Behind was an algebraic data type, let's say "LoggerState".<br>
<br>
The API provided methods to add a message like this:<br>
<br>
addError :: String -> Logger ()<br>
addError "Fatal error occurred"<br>
addWarning "Some warning" <br>
etc.<br>
<br>
There were methods to enter and exit the context:<br>
<br>
enterContext :: String -> Logger ()<br>
exitContext :: Logger ()<br>
enterContext "System x"<br>
enterContext "SubSystem x.y"<br>
enterContext "Module x.y.z"<br>
exitContext<br>
exitContext<br>
exitContext<br>
<br>
Well, the context was stored in an attribute of LoggerState, let's
call it ctx.<br>
The add function would pick the current ctx and add it to the
message.<br>
A message was defined as: ([Context], (State, String)) where State
was Ok, Warning, Error.<br>
<br>
This, however, violates the associativity. In consequence, the
context of messages would depend on parentheses, e.g.:<br>
<br>
someFunction :: Logger ()<br>
someFunction = do<br>
enterContext "A"<br>
addError "Some Error"<br>
callSomeOtherFunction<br>
exitContext<br>
enterContext "B"<br>
...<br>
<br>
produces a different result than:<br>
<br>
someFunction =<br>
enterContext "A" >><br>
addError "Some Error" >><br>
callSomeOtherFunction >><br>
exitContext >><br>
enterContext "B" >><br>
...<br>
<br>
Imagine:<br>
<br>
someFunction =<br>
enterContext A >> <br>
(addError "Some Error" >><br>
callSomeOtherFunction >><br>
exitContext)<br>
enterContext "B"<br>
...<br>
<br>
Here, addError and callSomeOtherFunction would operate on a
LoggerState without any Context,<br>
whereas in the previous example, there is context "A".<br>
<br>
Without the associativity law, it would be very hard to determine
the current state of the monad. <br>
Since the compiler, on "desugaring" do-blocks, will insert brackets,
there is no guarantee that the results are the same as for the
brace-less and sugar-free version of the code. <br>
<br>
Hope this helps!<br>
<br>
Tobias<br>
<br>
On 01/17/2011 04:21 AM, C K Kashyap wrote:
<blockquote
cite="mid:AANLkTinCjHkDBsHPYGzjZJPnRwvDsDkxnV7n2MQ76eBX@mail.gmail.com"
type="cite">Hi,
<div>I am trying to get a better understanding of the "monad laws"
- right now, it seems too obvious</div>
<div>and pointless. I had similar feelings about identity function
when I first saw it but understood its use</div>
<div>when I saw it in action.</div>
<div>Could someone please help me get a better understanding of
the necessity of monads complying with these laws?</div>
<div>I think, examples of somethings stop working if the monad
does not obey these laws will help me understand it better.</div>
<div>Regards,</div>
<div>Kashyap</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Haskell-Cafe mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://www.haskell.org/mailman/listinfo/haskell-cafe">http://www.haskell.org/mailman/listinfo/haskell-cafe</a>
</pre>
</blockquote>
<br>
</body>
</html>