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.
Name of function Show a => a -> Text
tshow
showt
T.show
- other (please comment)
2 Likes
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).
13 Likes
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:
- Use
Prelude.putStrLn
or similar and feed String
s to it to get dirty debug strings;
- Have a proper logger setup that accepts
Text
or Builder
s 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.
1 Like
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.
3 Likes
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
.
2 Likes
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.
3 Likes
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
3 Likes
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.
1 Like
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
2 Likes
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!
8 Likes
Thanks for championing this, @L0neGamer! And thanks to @Lysxia for implementing it so quickly!
6 Likes