New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tshow function #183

Closed
mightybyte opened this Issue May 25, 2017 · 18 comments

Comments

Projects
None yet
9 participants
@mightybyte
Copy link

mightybyte commented May 25, 2017

In multiple different projects that I have worked on I've encountered variations on the following function:

tshow :: Show a => a -> Text
tshow = T.pack . show

It would be great if the text package could add this to eliminate the redundancy and confusion.

@RyanGlScott

This comment has been minimized.

Copy link
Member

RyanGlScott commented May 25, 2017

A variant of this has been proposed before (and rejected) in #106.

@mightybyte

This comment has been minimized.

Copy link
Author

mightybyte commented May 25, 2017

That's actually a different thing. The text-show package gives you a standalone type class specifically for the purpose of converting to a Builder. I'm specifically talking about the existing Show class. That package also has more dependencies than text, and is therefore not an acceptable answer for what I want.

@ryantrinkle

This comment has been minimized.

Copy link

ryantrinkle commented May 25, 2017

Perhaps it would make sense as Data.Text.show? In the spirit of many other functions that are defined in Data.Text and generally imported qualified (e.g. null, map, reverse, etc.), this would be a direct analogy of Prelude.show.

@mightybyte

This comment has been minimized.

Copy link
Author

mightybyte commented May 27, 2017

I don't have much of an opinion what the name is. I'm just interested in squashing the unnecessary proliferation and fragmentation of pointless reimplementations of this function.

@alexeyzab

This comment has been minimized.

Copy link

alexeyzab commented Jul 7, 2017

Hi there! Is this issue still relevant? If so, would any of the maintainers be interested in providing some mentorship/general help on resolving this so that the newcomers and first-time contributors would have an easier time?

I would like to add this as one of the issues for the upcoming Haskell Weekly's Call for Participation section. See discussion in #75.

These are the guidelines we'd like to stick to in the future:

  • Ensure that your project has at least one open-source licence. (we've decided to not define the term "open-source" and it is left to your own interpretation).
  • Ensure that the issue tracker for your project is publicly accessible.
  • Create a new issue in your issue tracker and clearly describe the task. Also mention the difficulty level (easy/medium/hard/tedious), either as a tag/label or somewhere in the title/description.
  • If you have specific requirements for contributors (e.g., copyright waiver), it must be mentioned in the description of the task (preferably with a link to CONTRIBUTING.md).

Thank you!

@mightybyte

This comment has been minimized.

Copy link
Author

mightybyte commented Jul 7, 2017

This is definitely still relevant, and it's a very easy issue to fix. The main question at this point is maintainer buy-in.

@alexeyzab alexeyzab referenced this issue Jul 7, 2017

Merged

Issue 63 #76

@taktoa

This comment has been minimized.

Copy link

taktoa commented Jul 13, 2017

Personally, I've written this function upwards of 20 times. +1

@codygman

This comment has been minimized.

Copy link

codygman commented Jul 13, 2017

@ryantrinkle

This comment has been minimized.

Copy link

ryantrinkle commented Jul 13, 2017

@codygman That makes sense, although I think there might actually be two different things people are talking about here:

  1. An alias for T.pack . show, just because it's super annoying to type that out all the time.
  2. A more performant way of producing Text representations of datastructures

To me, these both seem very useful, and possibly quite different. For (2), I'm not sure what kinds of implementations people have in mind, but it seems like it might be a lot more involved than (1). In particular, it's not clear to me whether or how we can enforce that (2)'s instances agree with "classic" Show instances.

If it makes sense to others here, I would personally really like to see a solution to (1) happen independently of (and sooner than) a solution to (2). However, I can't say I've thought about the matter deeply, and I certainly wouldn't want something introduced that makes things tougher down the line.

@RyanGlScott

This comment has been minimized.

Copy link
Member

RyanGlScott commented Jul 13, 2017

Indeed, I'd be fine with fixing (1) in isolation.

As for (2), there are a number of solutions currently available. There's @bos's own text-format, and there's also my own text-show library, which aims to be character-for-character compliant with Show for Strings.

@mightybyte

This comment has been minimized.

Copy link
Author

mightybyte commented Jul 13, 2017

This issue is specifically asking for (1), not (2).

@RyanGlScott

This comment has been minimized.

Copy link
Member

RyanGlScott commented Jul 13, 2017

Sure, I'm not proposing that we implement (2) in text. (I only mention it since some folks here appear to want (2), or are at least waggling their eyebrows furtively in that general direction.)

@codygman

This comment has been minimized.

Copy link

codygman commented Jul 13, 2017

@mightybyte

This comment has been minimized.

Copy link
Author

mightybyte commented Jul 13, 2017

@codygman No, 2 does not address 1. Sometimes you actually want the existing Show type class. If we could rewind the clock and make Show render to Text instead of String, then 2 could address 1. But we can't, and therefore there are times when you specifically want Show because that is what is used by other code. It also should not be called show because that conflicts with the function exported by Show. It should be called tshow or something similar.

@eyeinsky

This comment has been minimized.

Copy link

eyeinsky commented Jul 18, 2017

I'd like this too! I've had tshow and tlshow available in most code I've written. Since these functions would be going into Data.Text/Data.Text.Lazy modules directly then I'd call them both show -- there's plenty of name overlap already, so people are already accounting for that.

@godygman I don't think hurt to the reputation about being slow will be an issue since due to the same overlap issue newbies need to do some work to actually use these functions, either by hiding show from prelude or explicitly qualifying it. In both cases they would probably encounter the documentation which explains the implications.

@bos

This comment has been minimized.

Copy link
Collaborator

bos commented Aug 8, 2017

Sorry, folks, I'm not going to take this. I know this is a widely used function, but saving 5 or 6 keystrokes isn't worth expanding an already-big API.

@bos bos closed this Aug 8, 2017

@mightybyte

This comment has been minimized.

Copy link
Author

mightybyte commented Aug 8, 2017

Hey Bryan, it's really about a lot more than 5 or 6 keystrokes. It's about uniformity and standardization. In different places and projects I've seen it called tshow, showt, and present. This presents a much higher cognitive overhead for everyone because people have to remember which variant is being used in the context they're currently working in. On top of this, people have to figure out where to put the function, as it doesn't have an obvious home in those contexts. The payoff / effort ratio is really high here.

@kindaro

This comment has been minimized.

Copy link

kindaro commented Jun 17, 2018

I revisited this ticket a few times, and however I try to persuade myself in the argument of @bos, my opinion remains unwavered. I must respectfully express my disagreement. I am also going to support it by mathematics.

  • The bigger the interface, the relatively cheaper is an addition of a single new entry point. ("A drop in an ocean.") At the same time, the speed of search in a large collection could be made logarithmic , thus allowing for very large (multiple volumes) paper dictionaries and encyclopediae. No one keeps the whole Text interface in their head at once anyway. Yet again, the performance of any individual function or the size of the build products would barely be affected beyond statistical significance, and even if they were, it would be filed as a GHC bug. Therefore the argument to an "already big" API does not stand, neither in humanitarian nor technological regard.
  • The longer the people have to type (pack . show), read (pack . show) with their eyes and mind, and define their own tshow aliases, the more savings accumulate. I would say the amount saved is the integral of the use of the library over time, so the more popular Haskell and Text become, the more keystrokes per second would be saved. Therefore, the argument to "saving 5 or 6 keystrokes" does not stand. (The basic version of this consideration was put forward by Edsger Dijkstra in EWD1300.)

The strategic consideration that I do not see mentioned before is that Text is supposed to supersede String in most regards. It already offers a replacement for many Stringy Prelude functions, such as readFile. There is no reason to make Show an exception, and, while it is infeasible to change the type of Prelude.show at the moment, there is nothing to fetter the provision of a drop-in replacement that is automagically consistent with the usual show.

In JavaScript, there would already be a widely used single function package on npm solving this problem. Haskell does not have this micropackage culture, so the maintainer is the king. This one time, the king's judgement is unsound.

@hvr hvr referenced this issue Oct 19, 2018

Closed

showText #237

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment