Add taggedTrace to Debug.Trace

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Add taggedTrace to Debug.Trace

Yuji Yamamoto
Nice to meet you, GHC Developers!
I'm new to contributing to GHC.

Today let me suggest new APIs of the Debug.Trace module, named:
  • taggedTraceShowId :: Show a => String -> a -> a
  • taggedTraceWith :: (a -> String) -> String -> a -> a
These are inspired by Elm's Debug.log function.
The prefix "tagged" is named after its argument.

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:
    • 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!

--

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: Add taggedTrace to Debug.Trace

Ben Gamari-2
Yuji Yamamoto <[hidden email]> 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.html>
>    :
>       - 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

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Edward Kmett-2
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 <[hidden email]> wrote:
>
> Yuji Yamamoto <[hidden email]> 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.html>
>>   :
>>      - 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
>
> --
>
>
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

Ben Gamari-2
Edward Kmett <[hidden email]> 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


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

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 <[hidden email]>:
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 <[hidden email]> wrote:
Edward Kmett <[hidden email]> 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

--



--
-Andrew Thaddeus Martin


--

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

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


2018年6月8日(金) 9:19 Yuji Yamamoto <[hidden email]>:
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 <[hidden email]>:
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 <[hidden email]> wrote:
Edward Kmett <[hidden email]> 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

--



--
-Andrew Thaddeus Martin


--


--

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: [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
<[hidden email]> wrote:

> Can anyone give me more feedback?
> I'm interested especially in my last reply.
>
>
> 2018年6月8日(金) 9:19 Yuji Yamamoto <[hidden email]>:
>>
>> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]> wrote:
>>>>
>>>> Edward Kmett <[hidden email]> 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.
>>>>
>>>> an email to [hidden email].
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> -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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

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

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

Oh, I see.
That's actually possible.
Okay, I'll withdraw my suggestion this time.

Thanks!

2018年6月12日(火) 14:25 Evan Laforge <[hidden email]>:
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
<[hidden email]> wrote:
> Can anyone give me more feedback?
> I'm interested especially in my last reply.
>
>
> 2018年6月8日(金) 9:19 Yuji Yamamoto <[hidden email]>:
>>
>> 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 <[hidden email]>:
>>>
>>> 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 <[hidden email]> wrote:
>>>>
>>>> Edward Kmett <[hidden email]> 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.
>>>> >>>> an email to [hidden email].
>>>> >>>
>>>
>>>
>>>
>>> --
>>> -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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


--

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs