Re: [core libraries] Re: Add taggedTrace to Debug.Trace

I agree that tags are necessary, and in fact I recently ported my internal debug library to cabal because now that I'm doing more stuff with cabal I find life too difficult without my accustomed debug library. For reference, it is this, but nothing fancy: https://github.com/elaforge/el-debug/blob/master/src/EL/Debug.hs So that's a vote for those things being worth it. But there are plenty of little things in there which mean I would still use my own library, not Debug.Trace, even if it did have a few extra functions. Such as pretty printing, forcing to avoid interleaved output, timeouts to avoid hanging, function return value tracing, and probably many more. And even after that, since there's no global agreed-upon Pretty class, I had to remove the Pretty variants, which means it loses a lot. And it may seem petty, but since I type them all the time, I'd want to use my short names, rather than the increasingly long and clunky ones in Debug.Trace. So rather than adding little bits to Debug.Trace to nudge it towards usefulness, maybe it would be better to make your own ideal debug trace library, and just use that wherever you go. On Mon, Jun 11, 2018 at 5:18 PM, Yuji Yamamoto wrote:

Can anyone give me more feedback? I'm interested especially in my last reply.

2018年6月8日(金) 9:19 Yuji Yamamoto :

...

Almost any formatting will do. At least I never care. I assume those APIs would be used for very ad-hoc use (like the other APIs in Debug.Trace). And debug codes put by such cases are deleted or disabled by NoTrace package in production. I want handy default functions available without batteries. Detailed formatting for debug messages should be configured by third-parties' logging libraries.

2018年6月8日(金) 4:29 Andrew Martin :

...

I am -1 on this. Such a function requires making a decision about formatting. What does a user expect from

...

taggedTraceShowId "meganum" (42 :: Int)

Any of these are reasonable:

meganum: 42 meganum [42] [meganum]: 42

In different applications I've worked on, I've wanted different flavors of something like this. Since there's no obvious choice, I don't think base is a good place for such a function.

On Thu, Jun 7, 2018 at 12:59 PM, Ben Gamari wrote:

...

Edward Kmett writes:

...

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

-- 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.

-- -Andrew Thaddeus Martin

-- 山本悠滋 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

-- 山本悠滋 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

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs