About two years ago bodigrim called for someone to get opinions on different name options for a function with the type in the title in https://github.com/haskell/text/issues/183#issuecomment-1276688584. I’m gathering such feedback now.
Please vote below. Discuss options and comment alternatives if you have good ones.
Show a => a -> Text
tshowshowtT.show0 voters
I voted T.show and I will justify my choice: Data.Text advises and is expected to be imported in a qualified manner in your code:
These modules are intended to be imported qualified, to avoid name clashes with Prelude functions
As such, conflict with the Prelude should not factor in the decision of the name. Much like Data.Text.IO has functions that may clash with the ones exported by the Prelude, but since you the end-user are expected to qualify the Data.Text.IO import, it’s also consistent with the System.IO API (and thus becomes more easily discoverable).
However let us remember that this is for the Show typeclass, whose semantics are very much oriented towards the printing of data structures in a way that exposes enough details to be parsed back by the Read typeclass. For a special-purpose output format directed towards users, there are alternatives out there like text-display.
I’m thoroughly confused by why the function would even be wanted because I view Show as a debug typeclass, as in my mind there are only two correct ways around:
Prelude.putStrLn or similar and feed Strings to it to get dirty debug strings;Text or Builders or whatnot. A streamlined converter from Show is possible for that logger package, albeit overwhelmingly for weird packages that abuse Show for serialization.Text.pack . show implies the existence of a midpoint between these two where you want quick-and-dirty performant (?) debug, so I would expect any such API function to be deemed a mistake in the future.
It’s not that the function is wanted, it’s that it sometimes is needed. Some (badly-designed, that’s my opinion) APIs will force you to use a Show a. I believe this is the main legitimate usage of Text.show, despite its requirement not being legitimate in the first place from the API, but not everyone can go and rewrite their dependencies’ APIs, especially if they are also deeply transitive.
It’s convenient to use this sort of function on numeric types, and in testing to glue things together without having to pack and unpack Strings and Texts; it’s overkill to use a dedicated package for this when it wouldn’t be used for other things.
sshow's existence could supplant this post’s topic’s function, but I wanted to follow bodigrim’s suggestion of just naming the text variant for now. A more polymorphic function like that could be useful in future, but this one is already contentious enough for now.
Then T.show. I would also add show :: Show a => a -> Builder.
showText, like it’s an actual name and not a puzzle to solve. Text.show is fine, but then I need to reexport such a common function from my own prelude and import said prelude in cases where I wouldn’t need to otherwise.
Why should debug code have to go through String? I don’t see why that has to be second class. We can have debug code and an efficient/sensible type for the output
Can you expand your questioning here?
I think we can all agree that it would be nice to just immediately use Text instead of going via String, but having this utility should not be blocked on trying to get Text into base or similar long term goals.
My point is that I don’t care about performance when using Show because I only use Show to dump datatype guts during development. It can be as efficient as any other way to encode data, I just don’t want newbies to think Show is how you serialize data for end users to consume.
I encourage further discussion of what we would ideally like the story of haskell’s strings to look like to continue in this thread: The Quest to Completely Eradicate `String` Awkwardness
We can then keep this thread on the topic of the particular function we’re trying to name/arguing against.
Ah right, yes, I see now that code still has to go through String but this just avoids a pack. I think I slightly misread the comment I was replying to. Still, I don’t see why using Show with a Text based logger isn’t worthy of being made a little bit easier
As of Add Data.Text.show and Data.Text.Lazy.show by Lysxia · Pull Request #608 · haskell/text · GitHub, show has been added to Data.Text and Data.Text.Lazy. Thank you for the voting and discussion, everyone!
Thanks for championing this, @L0neGamer! And thanks to @Lysxia for implementing it so quickly!