Add functions traceWith, traceShowWith to Debug.Trace

[ChickenProp]

(Historical note: originally this used On instead of With, but consensus seems to prefer With.)

These could be implemented simply as

traceWith :: (a -> String) -> a -> a
traceWith f a = trace (f a) a

traceShowWith :: Show b => (a -> b) -> a -> a
traceShowWith f a = traceShow (f a) a

I'd frequently find these functions useful when debugging, to give me just a small part of the large data structure being produced. But since I don't keep Debug.Trace imported long-term, I'm not going to have these defined as helper functions anywhere, so I basically just end up writing the definition inline - where I want traceShowWith f a I'd write (\x -> traceShow (f x) x) a which is awkward and obscures the actual code I'm trying to debug.

(I think flip traceShow <*> f is the same, but I wouldn't be confident I've remembered it correctly - and when I'm debugging, the last thing I want is to be wondering whether my debugging functions are doing what they should.)

This is admittedly only a mild quality-of-life improvement. But I think it's low cost. There's potential breakage because it adds exports, but I'd strongly expect there to be little-or-none in practice, and it's easy to fix where it does show up.

ETA: @noughtmare points out we'd also want to do this for traceEvent.

[JakobBruenker]

There's potential breakage because it adds exports

For what it's worth, https://hackage-search.serokell.io/ shows that neither name is defined anywhere in hackage.

[andreasabel]

With traceOn I associate code that traces if a specific condition is fulfilled. I'd like traceWith better.
Btw. something like (1)

traceWith :: (a -> String) -> a -> a
traceWith f a = trace (f a) a

would trivialize traceShow to traceWith show.

https://hackage-search.serokell.io/?q=traceWith lists exactly (1) as part of DebugTraceHelpers-0.12.
https://hackage-search.serokell.io/?q=traceShowWith has traceShowWith with the suggested implementation.
( Code here: https://hackage-search.serokell.io/viewfile/clash-lib-1.4.6/src/Clash/Debug.hs )

So, crowd intelligence supports my choice of names.

[ChickenProp]

If I was looking for these functions, I'd expect them to be named On by analogy with sortOn, groupOn and nubOn; but then, there's no traceBy and they can't be implemented using the on function, so maybe it's a weak analogy. With would certainly be the next choice - Data.List.NoneEmpty uses sortWith and group[All]With[1] (plus GHC.Exts defines sortWith and a different groupWith), but I've previously grumped about that state of affairs and I'd feel like using With here is getting more confusing, not less.

That said, I'm not inclined to fight about the names, if people prefer With then so be it.

[andreasabel]

Language is what people speak.
(Esperanto is the exception here, but it did not really catch on, did it?, despite best efforts.)

So, in picking a name for a function the first thing I ask myself is what name people have used before... (I.e., going on a field study...)

[treeowl]

@andreasabel, Esperanto has done quite well as conlangs go. I have a friend who speaks it with her children, as well as Esperanto-speaking friends.

[andreasabel]

@andreasabel, Esperanto has done quite well as conlangs go. I have a friend who speaks it with her children, as well as Esperanto-speaking friends.

Haha, should have abstained from that comment...

[ChickenProp]

Language is what people speak.

I will note that I am also a person. I haven't published anything using On, but I still "speak the language" where this is called On.

Like, it seems reasonable to say "it looks like more people would expect With than On here", those search results are definitely evidence for that. But I don't think we're at the point of "it's clear that a clear majority of people will expect these to be With". Not that you said we were, but it seemed worth making that distinction explicitly.

(And to repeat, I'm not really invested in this. I think the question of which to use and why is interesting but not very important; I kind of enjoy talking about it, but if there's a risk that talking about it will derail things I'd rather stop.)

[ChickenProp]

CLC, can you vote on this please?

[tomjaguarpaw]

I like the idea of doing something along these lines. Taking the name traceWith by way of example, I think we have

trace s = traceWith (const s)
traceId = traceWith id
traceShow s = traceWith (const (show s))
traceShowId = traceWith show

-- Additionally
traceShowWith f = traceWith (show . f)

To me those read more nicely than the On versions:

trace s = traceOn (const s)
traceId = traceOn id
traceShow s = traceOn (const (show s))
traceShowId = traceOn show

-- Additionally
traceShowOn f = traceOn (show . f)

I can imagine replacing all my uses of the existing Debug.Trace above with simple applications of traceWith! That makes me think it is worthwhile adding.

The last equation makes me think we shouldn't add traceShowOn/With because the delta from traceOn/With (show . f) is very small and I don't see a strong reason to privilege Show here.

[Bodigrim]

@ChickenProp sorry for dropping the ball. I've just posted this link on Reddit, hoping for a wider community discussion of the proposal.

[noughtmare]

If this goes through, I would also expect a traceEventOn/traceEventWith.

[vlatkoB]

Maybe traceAs would be clear that we want to show it As something else, traceAs :: (a -> String) -> a -> a?
And traceOn would be traceOn :: (a -> Bool) -> a -> a, a conditional trace?

[chshersh]

relude has the traceShowWith function in the same spirit as proposed here.

If you're interested in more context behind introducing this function, you can check the original discussion:

• Add 'traces' function kowainik/relude#301

[tomjaguarpaw]

Thanks @chshersh. Did you consider a function of type (a -> String) -> a -> a? To me that seems like the more important one to add. Repeating what I said above, traceShowWith f = traceWith (show . f) but to get traceWith in terms of traceShowWith you have to do something like

newtype ShowStringDirect = ShowStringDirect String

instance Show ShowStringDirect where
    show (ShowStringDirect s) = s

traceWith f = traceWithShow (ShowStringDirect . f)

Unless I've missed something, the relative simplicity of one direction and the relative complexity of the other suggests we should just add a function of type (a -> String) -> a -> a.

[chshersh]

@tomjaguarpaw The person who implemented the PR only wanted the Show version. I don't mind having traceWith in relude with the proposed type signature 👍🏻 So anyone who cares enough can open a PR 🙂