Skip to content
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

Deriving FromField/ToField instances? #206

Open
stevladimir opened this issue Nov 17, 2021 · 6 comments
Open

Deriving FromField/ToField instances? #206

stevladimir opened this issue Nov 17, 2021 · 6 comments

Comments

@stevladimir
Copy link

There is an API for deriving ToRecord/FromRecord instances, but none for ToField/FromField.
I looked through opened and closed issues and was unable to find any discussion regarding this.

Are there any deep reason's for not having generic instances for ToField/FromField?

@andreasabel
Copy link
Member

Over to @tibbe and @hvr ...

@phadej
Copy link
Contributor

phadej commented Nov 19, 2021

How these instances would work? ToField/ FromField instances are "leaf"s: parsing a cell value into haskell value. What Generics would do there? I can think of deriving for newtypes, but these can be derived using newtype strategy anyway.

@stevladimir
Copy link
Author

There can't exist reasonable encoding for all cases, e.g. for product types. But it exists for subset of sum types with constructors of 0- or 1-arity:

data Foo = Foo

data Foo = Bar | Baz Int

It's similar to UntaggedValue encoding from aeson. IIRC it should be possible to provide instances only for those cases without any dirty hacks.

@phadej
Copy link
Contributor

phadej commented Nov 19, 2021

Enum case makes sense. 1-arity is suspicious.

I'd suggest defining newtypes to be used with deriving via so the user tells what they want (instead of using clever generics trying to guess). That has an additional benefit that deriving mechanisms stay independent.

FWIW, I plan to make that change to aeson (in year or so, I'm not keen to break people too often).

stevladimir added a commit to stevladimir/cassava that referenced this issue Nov 20, 2021
Works only for the following representations:
* Single nullary constructor
  By default encodes constructor name
* Sum with nullary or unary constructors
  Encoding is similar to 'UntaggedValue' encoding from 'aeson'
@stevladimir
Copy link
Author

Enum case makes sense. 1-arity is suspicious.

I'd suggest defining newtypes to be used with deriving via so the user tells what they want (instead of using clever generics trying to guess). That has an additional benefit that deriving mechanisms stay independent.

FWIW, I plan to make that change to aeson (in year or so, I'm not keen to break people too often).

I think we can select precisely which instances to allow (see PR).
It works only for 'single nullary' or 'sum with 0,1 constructors' types and doesn't allow deriving for newtypes.
Actually, another option could be not adding default method at all, so user would have to write instance explicitly in case of such need.

@stevladimir
Copy link
Author

FWIW, I plan to make that change to aeson (in year or so, I'm not keen to break people too often).

Yeah, I like the idea. Current behavior is slightly confusing

andreasabel pushed a commit to stevladimir/cassava that referenced this issue Jul 10, 2022
Works only for the following representations:
* Single nullary constructor
  By default encodes constructor name
* Sum with nullary or unary constructors
  Encoding is similar to 'UntaggedValue' encoding from 'aeson'
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants