-
Notifications
You must be signed in to change notification settings - Fork 36
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
Lifting Pretty to * -> * & * -> * -> * #39
Comments
For reference, here’s the implementation I’m working with currently: (I’d document everything before submission, of course.) |
Hm, the code doesn’t really look very nice, but since we now have Show1 etc. in Base, I think this is something we could include. I’d like to keep it minimally invasive though – from a Haddock standpoint, there shouldn’t be too many new exports, the (single exposed main) module is long enough as it is. Can you explain why |
I’ll do my best to match project style 😊
Okay, you bet 👍 Would you be interested in including a generically-derivable implementation of I’m guessing not given the above, but wanted to double-check since it wouldn’t necessarily have to increase the API’s surface area.
Oh, my bad—I don’t think we should include it at all. It’s a convenience to give you a |
I don’t think Pretty1 should be derivable (likewise for Pretty), since prettiness is not something that follows any laws. If push comes to shove and we really need a quick Pretty instance, writing the instance without any definitions will just fall back to |
I’m closing this issue since the corresponding PR (#40) looks good enough to subsume it. |
Would you be open to a PR defining liftings of
Pretty
to * -> * and * -> * -> *, a laShow1
&c. fromData.Functor.Classes
? It makes (decidable) recursive instances forFix
,Free
,Cofree
&c. much easier to define:If so, I’ll be happy to submit one 😊
The text was updated successfully, but these errors were encountered: