Add a `Warn` constraint to `show`

[natefaubion]

Somewhat controversial, but I've seen far too many shows make it into production code 😛

[hdgarrood]

What about types like Int or Number? There are reasons to show them in production code and I don't think there's a way of doing that without using Show.

[natefaubion]

Number's show instance is rarely desirable in production because its not often you want the trailing .0. That leaves only Int, which makes abstracting over Show not very useful.

So, I'd say move https://pursuit.purescript.org/packages/purescript-numbers/4.2.0/docs/Data.Number into core and export Data.Number.print and Data.Int.print. We could also export Data.Number.prettyPrint which removes the trailing .0.

[paf31]

I like this idea, but there are valid uses for show. Debug statements in logs is one that jumps to mind.

[natefaubion]

noReally :: forall a sym. (Warn sym => a) -> a

noReallyShow a = noReally (show a)

Or at least don't export show from Prelude. It's too accessible, so authors reach for it when it's almost never what one wants.

[hdgarrood]

When you have a Number which happens to be non-integral, which does happen quite often in certain domains (e.g. games), you do want to see the fractional part of it.

Also, I'm not sure adding a Warn constraint and also exporting a new function noReallyShow would really accomplish anything other than confusing and annoying people who don't follow discussions like this one on all the GitHub repos; the API is essentially the same, except old code will suddenly start producing a bunch of warnings. I very much agree that I'd like Show to change but I don't think this is the right way to go about it. I think I'd prefer people try this approach in a custom prelude first and see how it goes, at the very least.

Separately, I'm keen to move that library into core, as it seems like something that we ought to have, although I'd prefer to remove the type aliases or possibly replace them with newtypes.

[paf31]

I'd like to see Show change too, but I think it's probably fine to leave it as-is at this point. There will be some rough edges here and there as we release 1.0, but I think that's okay.

[natefaubion]

We are going to export a version of show carrying a Warn constraint in our internal SlamData.Prelude and see how it goes.

[garyb]

I guess we're probably not doing this, or not in the near future at least. We never quite did get around to adding the constrain in SlamData either 😄