-
Notifications
You must be signed in to change notification settings - Fork 50
Add generic deriving #40
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
Conversation
👍 |
@paf31 Would you say this is a breaking change? I mean, it isn't, but the new version won't work in older version of |
I think it should be a conscious decision to upgrade, and a major bump is the only way we have to ensure that, so yeah. |
In that case:
I'm not sure how comprehensive this tool is that I use to generate these, there must be some kind of bug in it as when I was doing the |
I'd suggest we add more derived generic instances and release them all as a batch if we're going down this route though, to prevent having to bump a bunch more times. |
Agreed, but what else needs a generic instance? I don't know if one for |
Good point, perhaps there isn't anything else that would need it :) Let's just be sure before we commit! |
We have various newtypes which might benefit from it. In |
Although of course that module can't depend on |
Good point, |
So, in regards to |
But then, e.g. |
That's how it basically is now, except for the qualified names and the extra, yet proper, parens - > singleton "foo" 1
fromList Cons (Tuple ("foo") (1)) (Nil)
-- With Generic (Map k v)
> data W = W (Map String Int)
> derive instance genericW :: Generic W
> instance showW :: Show W where show = gShow
> W (singleton "foo" 1)
W (Data.Map.Map.fromList (Cons (Data.Tuple.Tuple "foo" 1) Nil))
|
@garyb Do we want to include this in 1.0? It seems harmless enough to me. |
Yeah, I think so! |
No description provided.