Is traceIO unnecessarily specialised to the IO monad?

[Chris Seaton]

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 at 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 at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130125/b9a2b2be/attachment-0001.htm>