[RFC] A sketch of a Read type class

[sideeffffect]

This is my first take on how a Read type class could look like in ZIO Prelude.

A Read type class could be handy for debugging and/or development purposed. For production use cases, we should urge our users to use full-fledged parsing/decoding/deserialization solutions, of course.

The most complex piece would probably be the parser Read.parse(string: String): Either[ReadException.ParseError, Debug.Repr]. But given that the structure of Debug.Repr is pretty tight, it shouldn't be that complicated.

What do you guys think?

Inspiration/Background:

• Haskell's built-in Read
• https://github.com/ChristopherDavenport/read
• Add Read typeclass typelevel/cats#932

[adamgfraser]

@sideeffffect Thanks for your work on this!

While interesting, I tend to think that we should not add this to ZIO Prelude. I come to that conclusion for a couple reasons.

First, my overall view is that we should if anything have fewer rather than more functional abstractions. I think libraries like this tend to have too many abstractions and while every abstraction has some benefit there is also a cost in making it less clear how people should use the library and more difficult to learn. So I think we should really focus on abstractions that have strong practical use cases.

Against this we have this abstraction that at least from my perspective seems to have relatively limited utility. It sounds like we're agreed that this is really for simple cases like debugging and in those cases at least in my experience data types have simple enough constructors that you can just construct them yourself.

In addition, I think it does not reflect well on this abstraction that it is only for relatively simple cases. I think one of the strong points of the ZIO ecosystem is that we provide tools that are relatively simple and accessible but also scale with you (e.g. I can get you started using ZManaged as "try / finally for asynchronous code" and you can grow with that all the way to dealing with the most sophisticated resource management problems imaginable). This seems like the opposite of that where there is significant complexity in doing the simple thing and then for complex things you need to switch to a completely different real parser.

A final consideration against is that one of the arguments for this, that otherwise Show is a lawless type class, doesn't apply to us. Debug already has a different law, which is that the Scala rendering of a Repr should itself compile as valid Scala code. Now we could definitely do more work in our testing infrastructure to verify that in an automated way, but that gives us a strong law for Debug that is completely independent of any other abstraction.

[sideeffffect]

Fair enough 👍