
Nice to meet you, GHC Developers! I'm new to contributing to GHC. Today let me suggest new APIs of the Debug.Trace http://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-Trace.html module, named: - taggedTraceShowId :: Show a => String -> a -> a - taggedTraceWith :: (a -> String) -> String -> a -> a These are inspired by Elm's Debug.log http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Debug#log function. The prefix "tagged" is named after its argument https://github.com/elm-lang/core/blob/5.1.1/src/Native/Debug.js#L5. I mean, these new APIs prepend a string as a tag to the output by traceShowId etc. It helps us recognize what the printed values stand for. I frequently want such functions and write them manually or copy-and-paste from the Debug.TraceUtils. I'm tired of that. That's why I made this suggestion. *Comparison with the existing solution* - Debug.TraceUtils http://hackage.haskell.org/package/TraceUtils-0.1.0.2/docs/Debug-TraceUtils.... : - Essentially, this suggestion is to add APIs already implemented by TraceUtils. - As the document of TraceUtils suggests, we can copy and paste the functions from its source, but it's still tiresome. - Combine Debug.Trace.traceShowId with Debug.Trace.trace: - e.g. trace "Tag" $ traceShowId x - A bit hard to type. - trace always prints a newline, which makes it difficult to tell the tags from the printed value. After receiving some feedback here, I'm going to submit to https://github.com/ghc-proposals/ghc-proposals Thanks in advance! -- Yuji Yamamoto twitter: @igrep GitHub: https://github.com/igrep GitLab: https://gitlab.com/igrep Facebook: http://www.facebook.com/igrep Google+: https://plus.google.com/u/0/+YujiYamamoto_igrep

Yuji Yamamoto
Nice to meet you, GHC Developers! I'm new to contributing to GHC.
Hi Yuji! Thanks for your proposal. I think this is likely best handled by the Core Libraries Committee (CC'd). Let's see what they say.
Today let me suggest new APIs of the Debug.Trace http://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-Trace.html module, named:
- taggedTraceShowId :: Show a => String -> a -> a - taggedTraceWith :: (a -> String) -> String -> a -> a
These are inspired by Elm's Debug.log http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Debug#log function. The prefix "tagged" is named after its argument https://github.com/elm-lang/core/blob/5.1.1/src/Native/Debug.js#L5.
I mean, these new APIs prepend a string as a tag to the output by traceShowId etc. It helps us recognize what the printed values stand for. I frequently want such functions and write them manually or copy-and-paste from the Debug.TraceUtils. I'm tired of that. That's why I made this suggestion.
*Comparison with the existing solution*
- Debug.TraceUtils http://hackage.haskell.org/package/TraceUtils-0.1.0.2/docs/Debug-TraceUtils.... : - Essentially, this suggestion is to add APIs already implemented by TraceUtils. - As the document of TraceUtils suggests, we can copy and paste the functions from its source, but it's still tiresome. - Combine Debug.Trace.traceShowId with Debug.Trace.trace: - e.g. trace "Tag" $ traceShowId x - A bit hard to type. - trace always prints a newline, which makes it difficult to tell the tags from the printed value.
After receiving some feedback here, I'm going to submit to https://github.com/ghc-proposals/ghc-proposals Thanks in advance!
Personally, I do like the "With" variant as I regularly find myself needing things like this. I'm a bit unsure of whether we want to bake the "tag" notion into the interface, however. Cheers, - Ben

What different users would do with such a prefix, how to display it, etc. varies just enough that i’m somewhat hesitant to grow the API. I’m a very weak -1. But I’d happily let anybody else on the committee override that if they had a strong preference. -Edward
On Jun 7, 2018, at 5:40 PM, Ben Gamari
wrote: Yuji Yamamoto
writes: Nice to meet you, GHC Developers! I'm new to contributing to GHC.
Hi Yuji!
Thanks for your proposal.
I think this is likely best handled by the Core Libraries Committee (CC'd). Let's see what they say.
Today let me suggest new APIs of the Debug.Trace http://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-Trace.html module, named:
- taggedTraceShowId :: Show a => String -> a -> a - taggedTraceWith :: (a -> String) -> String -> a -> a
These are inspired by Elm's Debug.log http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Debug#log function. The prefix "tagged" is named after its argument https://github.com/elm-lang/core/blob/5.1.1/src/Native/Debug.js#L5.
I mean, these new APIs prepend a string as a tag to the output by traceShowId etc. It helps us recognize what the printed values stand for. I frequently want such functions and write them manually or copy-and-paste from the Debug.TraceUtils. I'm tired of that. That's why I made this suggestion.
*Comparison with the existing solution*
- Debug.TraceUtils http://hackage.haskell.org/package/TraceUtils-0.1.0.2/docs/Debug-TraceUtils.... : - Essentially, this suggestion is to add APIs already implemented by TraceUtils. - As the document of TraceUtils suggests, we can copy and paste the functions from its source, but it's still tiresome. - Combine Debug.Trace.traceShowId with Debug.Trace.trace: - e.g. trace "Tag" $ traceShowId x - A bit hard to type. - trace always prints a newline, which makes it difficult to tell the tags from the printed value.
After receiving some feedback here, I'm going to submit to https://github.com/ghc-proposals/ghc-proposals Thanks in advance!
Personally, I do like the "With" variant as I regularly find myself needing things like this. I'm a bit unsure of whether we want to bake the "tag" notion into the interface, however.
Cheers,
- Ben
-- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout.

Edward Kmett
What different users would do with such a prefix, how to display it, etc. varies just enough that i’m somewhat hesitant to grow the API. I’m a very weak -1. But I’d happily let anybody else on the committee override that if they had a strong preference.
Right, as I mentioned I'm not sure about the tagging idea. However, I have found things of the form `(a -> String) -> a -> a` handy in the past. Then again, it's pretty trivial to open-code this when needed. Cheers, - Ben
participants (3)
-
Ben Gamari
-
Edward Kmett
-
Yuji Yamamoto