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
Even more general map serialising #341
Conversation
ac10427
to
ef21759
Compare
This is a bit problematic on |
Sadly, you can't have a polykinded |
Well, here I don't actually need polykinded proxy. So I can make this work with special type. |
5d366a8
to
6e723f8
Compare
http://oleg.fi/aeson-bench.html result of |
Should I be closing #339 in favour of this? |
5c6da22
to
06de712
Compare
I see the benefits of generalizing key handling, I've wanted it multiple times myself (we even have our own package for it!)
|
06de712
to
cd76267
Compare
@bergmark, from the last commit you can see that errors are clean, actually clearer than previously:
For the second point, I marked instances About 3rd point I'm not sure. It's true that if you have somewhere If there is a way to grep Hackage for those instances, I could check the packages against this branch. Yet probably most of them live in private application code. |
P.S. travis fail due GHC8.0, looks like something dependency related... |
I made a small test:
results in: https://gist.github.com/phadej/6dd08254e6fbcdc4fc13 There are errors like
and
but none related to EDIT: not the cleanest experiment setup, but that's what I got today |
299c8de
to
234f9c1
Compare
234f9c1
to
f6266bb
Compare
254b6d6
to
eb37633
Compare
eb37633
to
38a0f32
Compare
Made it possible to serialise maps as list of key value pairs (for complex keys). Now GHC 7.4 panics :/ |
Also it would be possible to have default implementations for |
I would like to offer some criticism of this branch, but first I just wanted to say thanks for doing this. This will be a fairly helpful feature for me. I strongly agree with the four options for key serialization that were decided on. Before looking at the branch, I hadn't even considered the Here's where I disagree with the design. I think that the use of GADTs, singletons, flexible instances, fundeps, MPTCs and type families is unnecessary for solving this problem. I would like to propose a feature-equivalent solution that doesn't use any of these. Basically, instead of having:
I think the following would be easier to understand and use:
With this, almost everything becomes simpler. The definition of
It would become the following:
The definition of Another thing to note is that even the
It would become:
Let me know if there is any concern that certain functionality or guarantees would be lost with this approach. I would be happy to implement these changes on this branch if others find this strategy agreeable. Thanks. |
@andrewthad We want to have uniform method per type, by using your Not that my approach could be probably "beautified" by tweaking stuff a bit. I must admit, I don't remember why I ended into current version. |
@phadej I don't understand what you mean when you say:
If we have:
We can then write:
This is still choosing a coersion technique on a per-type basis, not on a per-value basis. |
@andrewthad Ah sorry, I missread... Have to think about! |
Also, I was thinking about this more, and regardless of which strategy is used, I'm suspicious that the special case for Here's my line of reasoning. The benefit of both coersion mechanisms (safe and unsafe) is that you can avoid walking over a structure. So, if we have:
And we want to write:
Then if we consider the following implementations:
The first one is more performant because it don't have to traverse the list. However, if we write:
It's just as performant as implementation (2) because we're still traversing the list (and applications of
We're still mapping over the |
I've been thinking about this a little more, and I'd like to present a situation in which the approach I've proposed ends up being more expressive than the existing implementation of this feature. If anyone is jumping into this conversation here, make sure to read [my earlier comment] where I outlined this alternative. If we're in a situation involving that involving a higher kinded type, we would like to be able to write
In this particular case, it's not a huge deal because I never have values of type These instances don't always produce super pretty keys. As an example, let's consider
We want a tuple serialization that would continue using textual keys (rather than value keys) if both types create textual key. One naive approach might use a separator:
This approach will not work for
Anyway, that's kind of a tangent, but I think that being able to offer this would be nice. I do sometimes want to serialize |
Just had another thought. If the
Then this function could be overriden in the |
More general version of #339
I'd prefer this one. Will write more instances & documentation if the approach is otherwise ok