Next steps for wider adoption

[milesfrain]

This Slack discussion outlines some ideas of what may be required for this library to gain wider adoption. Compiler support may be required.

unfortunately it seems like it'll take some time for something like this to percolate through the library ecosystem though, no? given that we can't have orphan instances, so everything needs to come pre-equipped with it, or the library needs to be forked

Yeah, that’s the main obstacle

If we adopt Debug, I think it's important to have compiler deriving for it. (Maybe even special rules for allowing orphan instances)

We can derive Debug via Generic with relatively little ceremony already

I'd like to make sure we can reliably omit Debug instances from production bundles... That also means to not have any of the Generic instances that solely exist to implement Debug I fear relying on DCE after the fact will be brittle Maybe I'm overthinking it..

Ah I see I think DCE is smart enough to do that already, but I’m not certain At least purs bundle ought to be

Basically I'd like to avoid the situation where I need to add 5 instances before I can start debugging something, only to then have to delete those again having Debug instances for everything ought to be the default, so we need to make sure it's "free"

[timjs]

To make this library practically usable, I very much agree that Debug should be automatically available for all types! No deriving needed, no orphans created. DCE should be powerful enough to automatically remove the generated code for every Debug instance.

[hdgarrood]

I'm hesitant about having it automatically available. There are definitely some types for which the derived instance would be wrong; Map and Set are examples. Also, the library is built to make it as easy as possible to define instances. I would prefer to wait until people start using it more widely so that we can see how it's being used before we start considering compiler support.

I think the main obstacle is this: if this library is to fulfil its purpose, we need to make it a given that every type should have a Debug instance. For that to be possible, the class probably needs to be exported by the Prelude. That's hard because this library depends on a bunch of stuff which isn't in Prelude.

[hdgarrood]

I've been thinking about this and while I think the eventual goal should be to have it be part of Prelude, I also think that needs to happen gradually - it's likely that we'll want to refine the design, and that's hard to do if we move it into Prelude too quickly. I think a good first step would be to move this library into core, and state that we intend to keep maintaining it as part of core, and that it should provide Debug instances for all data types in core. That way, people will be able to have more confidence in depending on it, which will allow it to gain wider adoption and hopefully provide feedback which helps us refine the design more.

[the-dr-lazy]

Any updates or related issues on this?

[hdgarrood]

I think there are still people interested in making this happen, but a) the focus recently has been on getting 0.15 out, and b) I think it’s still a bit awkward because of the dependency issues I mentioned in my previous comments.