A somewhat radical proposal for Show

[hdgarrood]

(Vaguely related to purescript/purescript-prelude#46.)

I think @jonsterling is on to something here (I recommend reading at least the first few replies as well): https://twitter.com/jonsterling/status/670091766549344257

I've felt vaguely uneasy about the Show type class for a long time and I think this hits the nail on the head. I think our current Show type class is unsuitable for debugging / use in the REPL (which ought to be its main aim) because:

• Some types have no Show instance, for example, (->). This doesn't seem so bad, because what use would showing a function be anyway? But it can be irritating when you want to print larger structures which contain types like (->). In particular, at the moment, you can't use Generic; you have to write out Show instances which skip over the "unshowable" things yourself.
• When you have a function that turns almost anything into a String, it's just too tempting to abuse it for serialization (as we have discovered in the Haskell community).
• The more types that do have Show instances, the more dangerous show becomes; given that it works on almost anything, and that the return type is just String (rather than something that mentions the input type like pure, for example) it's very easy to call show on the wrong thing. It's almost like using a dynamic language!
• Records can't have instances, even though there's no technical reason that they couldn't be printed for debugging.

@jonsterling suggests having print :: forall a. a -> Unit instead, similar to the existing purescript-debug library.

I think we could improve this situation significantly by having a compiler-supported Show replacement.

I propose that we add a type class to the compiler. Let's call it Debug (it wouldn't depend on purescript-foreign, this is just to illustrate):

class Debug a where
  debugShow :: a -> Foreign

Where the return type of debugShow is anything that is suitable to be passed to console.log. Sometimes this will just be a String, but often I think it's a good idea to leave other types as they are, as browsers can offer nicer UIs. Try console.log({foo: 1}) in Firefox or Chrome for instance.

This type class would be invisible to the user, if possible, but we also provide a function which is visible, something like print :: forall a. (Debug a) => a -> Unit, or perhaps closer to the types in purescript-debug, and which internally does console.log <<< debugShow before returning unit.

We add a special case in the compiler so that every type is an instance of Debug, including functions and records. Defining your own instances is not allowed. This way, we don't need to worry about orphans and all that (I think).

These instances would probably do something like:

• If it's a record, iterate over the properties and call debugShow on each.
• If it's an array, simply map debugShow.
• If it's an ADT defined in PureScript code (ie data or newtype), do the same thing as the what the derived Show instance in Haskell would do.
• Types defined via foreign import data could probably be left alone.
• Functions could be left alone. Browsers already do a decent job of printing these. Alternatively, we could include the type: print id might produce "<Function: forall a. a -> a>".
  and so on.

If print occurs in your program, it generates a compiler warning, which helps you avoid accidentally leaving them in.

print could also include the current file name and line number.

I realise this is, to some extent, at odds with the current minimalistic approach of the compiler. But to me, it appears promising enough to justify bending the rules a little. And I think it would allow us to get rid of Show. This would not only make me happy not only because Show unnerves me, but also because it would take us most of the way to removing all the runtime dependencies of psci — If we also moved the Eff type into Prim then $PSCI.Support could have no library dependencies, which would resolve #1441.

[garyb]

I like it. I think a conversion to String is still preferrable though, as if you're debugging you'll often want to output some words, not just a value, as it becomes very difficult to distinguish what log line refers to what otherwise. The fact that the string it generates would be useless for anything other than debugging and cannot be overridden avoids the serialization-temptation problem.

I'm not so sure converting-anything-to-String even counts as an effect then, so we can still use it with purescript-debug or something to actually print the message.

edit: rather, conversion-to-printable-value, perhaps Foreign or some opaque type is better than String, as you say.

[hdgarrood]

You'll often want to output some words, not just a value

Maybe just creating a record would be a enough? Suppose you want to print x, y, and z, then:

print { x, y, z }

Or even

print { msg: "About to do something", x, y, z }

[garyb]

That's true, or event just provide a print' which accepts a message and a value.

[hdgarrood]

I've recently come across an instance where it would be useful to get the String, actually: when writing a testing framework. For example, if you were writing an assertEqual function, you'd want to be able to generate a message like "Expected X but got Y", and you would want more control than just being forced to print it immediately.

It's just a bit unfortunate that having a forall a. a -> String would break parametricity, as foo :: Array a -> Array a could then use this debugShow function to inspect its arguments, for instance.

[hdgarrood]

Oh wait, no, you don't need to convert to String there - in that case you can instead hold on to an some type like Array (exists a. { expected :: a, actual :: a }), using a Writer monad or something, and print stuff in it whenever you want.

Although this specific use case does reveal another thing: if we had a print function which automatically included file name, line number, and column number, we'd probably want to be able to turn that off.

[sharkdp]

I like your proposal. But what if I really want to convert a value to a String for the actual purpose of the program? How would I convert an Int or a Number to a String?

[hdgarrood]

We would add extra functions for those things, I guess. I would argue that they should be monomorphic.

[robotlolita]

A big 👍 from me on this. It would be nice if print (x -> x) gave you something like: x -> x :: forall a. a -> a

@sharkdp a ToString type class would be the best thing for that:

class ToString a where
  toString :: a -> Maybe String -- not all things can be converted

This is total and goes nicely with the reverse too:

class ParseFromString a where
  fromString :: String -> Maybe a

But using a specific serialisation format (like JSON or Transit or whatever) might be better suited for your use case. You can also create type classes for that. The problem with Show is just that there are no rules on "what should I output here?", so it's kind of a bad fit for all problems it could be used for.

[paf31]

Perhaps the way to implement this is to have move Show into Prim, and have the constraint solver insert the correct dictionary automatically during solving. This would lead to some code explosion, but it would be understood that Show is for debugging only. Maybe the name could be changed to reflect that.

[hdgarrood]

Maybe the name could be changed

👍. Rust called theirs Debug which I think is probably as good a name as any.