Specialize trace to Text

[srghma]

relude/src/Relude/Debug.hs

Lines 78 to 79 in 85ab6f9

	trace :: String -> a -> a
	trace = Debug.trace

https://github.com/sdiehl/protolude/blob/7c0e45c844bedd311ecabf7c423039a98758a453/src/Debug.hs#L28-L32

[chshersh]

Hi, @srghma, we don't have the Print typeclass (as in your link from protolude) because one of our goals is to strive to have fewer custom abstractions. Another of our goals is to be beginner-friendly and have fewer surprises from Prelude and base when possible and when it doesn't conflict with other goals. We don't have a goal to replace each String with Text. However, we do have a goal to be performant. But trace is not used in production, it's a debugging-only function, so it's performance is not critical. That's why the type of the trace argument was chosen as String intentionally.

[srghma]

can we allow IsString ?

[chshersh]

@srghma It's not possible to specify the type of the trace argument as IsString. Because IsString has only the following method:

fromString :: IsString s => String -> s

You will be able to pass to trace values of any type that implements IsString typeclass, but we won't be able to use it in the trace from base because it's not possible to implement the following function:

fromIsString :: IsString s => s -> String

[srghma]

didnt know

well, I could propose to use ToString class, but seems like you don't want and thus I see no reason to continue

[chshersh]

@srghma Yes, we have our own ToString, and it could work here. It's not that I don't want; there are just two incompatible solutions. With ToString it's more convenient to pass String or Text as an argument, but it's more challenging to work with polymorphic overloaded literals. So trace $ "Calling function foo with an argument: " <> show x will become a compile-time failure due to ambiguous type. So you either use explicit conversions in the case for monomorphic kinds (current behaviour), or you use explicit type annotations (proposed this issue). There's no win-win situation, and it's always about trade-offs. We just decided to choose the first option because for us it makes more sense, it's more convenient and beginner-friendly. Also, it's usually a good general rule I found beneficial when writing Haskell programs to follow the design approach to have polymorphic results instead of polymorphic arguments.