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

[Evan Laforge]

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
<whosekiteneverfly at gmail.com> wrote:
> Can anyone give me more feedback?
> I'm interested especially in my last reply.
>
>
> 2018年6月8日(金) 9:19 Yuji Yamamoto <whosekiteneverfly at gmail.com>:
>>
>> 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 <andrew.thaddeus at gmail.com>:
>>>
>>> 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 <ben at smart-cactus.org> wrote:
>>>>
>>>> Edward Kmett <ekmett at gmail.com> 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 at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>