Added generic conversions using new style GHC Generics. #3

Merged
merged 5 commits into from Aug 27, 2012

Projects

None yet

4 participants

@sjoerdvisscher

I did not use the trick with default implementations and the default signatures extension, so Data.Csv will stay compatible with older GHC versions. But you could add them and stay compatible by using conditional compilation.

@jberryman

heh, you beat me!

@tibbe
Collaborator

(Adding Bas as I think he worked on the generics support for aeson.)

@sjoerdvisscher @jberryman @basvandijk I don't understand generics well enough. Could you guys together come up with a design? It'd be nice if it's not too invasive (e.g. adds lots of exports). Perhaps modeled after the aeson one?

@sjoerdvisscher

I think this follows the design of aeson pretty closely (except using the new GHC generics).

@sjoerdvisscher

Oh, wait, aeson also has the defaults using conditional compilation. I'll see if I can add that.

@jberryman

I'm mostly interested in questions raised in my commit w/r/t:

  1. whether separation of fromField and fromRecord is really necessary, rather than just having recursive instances which would seem at first glance to simplify things

I think the separation makes sense CSV (unlike JSON for example) as strictly a two level structure. Having things split into FromField and FromRecord/FromNamedRecord lets the latter two share instances. Do you have an example of what a one-level hierarchy might look like?

@sjoerdvisscher

Re #2: Good thing you asked! In parseRecord it tries all the constructors that have the same number of fields as the given vector. In parseNamedRecord it just tries all the constructors. The first one that succeeds is returned. But because I use an IntMap to store the parsers by number of fields, the order the constructors are tried was from fewest to most fields. So I flipped the (<|>) so now it tries the constructor with the most fields first.

I don't think sum types will be used much in practice, except perhaps to support parsing of differing CSV formats, f.e. because of versioning.

@jberryman
@tibbe
Collaborator

I'm stil trying to figure out how this implementation relates to the aeson one. In aeson there's a Data.Aeson.Generic module. How come we don't need one? Does aeson have two different kinds of generics support?

@basvandijk

Does aeson have two different kinds of generics support?

It actually has three different kinds:

  • Data.Aeson.Generic exports the old SYB based generics support.
  • Data.Aeson.TH exports the template haskell automatic deriving support.
  • Data.Aeson exports the normal FromJSON and ToJSON classes which have default generic methods which I added a while ago (using the new DefaultSignatures extension).
@tibbe
Collaborator

@basvandijk Is it enough for us to support the third kind?

@basvandijk

@tibbe Yes (Although the template-haskell automatic deriving does generate faster code for sum types).

@tibbe
Collaborator

@basvandijk I understand what sum types mean in the context of aeson, but I'm not sure we'll see many encoded as CSV, unless sum types here also include instances of ToField/FromField for simple enum types (like my Color example in the docs).

@tibbe
Collaborator

The patch looks fine from what I can see and it implements Bas' 3rd bullet point. Anything else we should consider before submitting?

@sjoerdvisscher

It could use some documentation. The way it is now you couldn't tell from the Haddock documentation that there's a default implementation for data types that implement Generic.

@tibbe tibbe merged commit e07b20c into hvr:master Aug 27, 2012
@tibbe
Collaborator

Thanks for the patches! We still need to update the docs and perhaps add a test or two.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment