Agreed, but I think that's the behaviour that you expect when tracing, and when you trace in a monad you would expect get the semantics of that monad as well. For example, you may be using traceM to check that your monad has the strictness behaviour that you expect.

I usually use traceM to view temporary values in a list or maybe comprehension, and then the semantics are obvious because I'm tracing a value that is about to be consumed by the next stage in the pipeline.

I could add some notes about it being best applied with certain monads.

Chris

On 25 January 2013 16:44, Patrick Palka <patrick@parcs.ath.cx> wrote:

Note that traceM won't work correctly for monads that are not strict in the first argument of >>=, e.g. the Identity monad.

For example, this will not print anything: runIdentity $ traceM "test" >> return ()

On Mon, Jan 21, 2013 at 11:48 AM, Chris Seaton <chris@chrisseaton.com> wrote:

I use printf-style debugging a lot, so I am always adding and removing applications of trace. There is the Debug.Trace.traceIO function that makes this easy to do in the IO monad (it just applies hPutStrLn stderr), but is that specialisation to IO unnecessary?

I find myself always using this utility function:

traceM :: (Monad m) => String -> m ()
traceM message = trace message $ return ()

Which can be used to implement traceIO.

traceIO :: String -> IO ()
traceIO = traceM

That way I can traceM in whatever monad I am in. It is easier to add and remove an application of trace, because I do not have to wrap it around something, and I do not have to remember the return. Of course, you are still subject to however your monad chooses to order the execution of these traces, but that is what people expect when using trace.

Would traceM be a wanted addition to Debug.Trace?

Regards,

Chris Seaton

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries