Provide type-level field names

[pkamenarsky]

Would you be interested in such a change? If yes I'll adjust the tests as well.

[soenkehahn]

@pkamenarsky, thanks for the PR!

Do you have a few examples for common use-cases where this would be useful?

generics-eot is designed above all to be as easy to understand and use as possible. This change would make the library more complicated. And for the common use-cases where users don't need type-level names, we don't get any benefit. So in general I'm skeptical that this would be a good change. But I'm happy to discuss. :)

[pkamenarsky]

@soenkehahn I completely understand that simplicity is important, especially when the standard Generic machinery is so convoluted. I'd be interested to see if there's another way to go about my use case.

Named gives you the ability to get to the field names using type families, for example:

type family LookupFieldType (field :: Symbol) (eot :: *) :: * where
  LookupFieldType name (Either records Eot.Void) = LookupFieldType name records
  LookupFieldType name (Named name field, fields) = field
  LookupFieldType name (Named otherName field, fields) = LookupFieldType name fields
  LookupFieldType name eot = TypeError ('Text "Can't lookup field type")

And then one could write a generic get that automatically infers the type of the accessed field:

get :: (HasEot a, LookupFieldType s (Eot a) ~ b, KnownSymbol s) => Proxy s -> a -> b
get = ...

Do you see a way to do this without Named?

[soenkehahn]

Hi @pkamenarsky. So sorry that it took over a year to get back to you! Not sure whether you're still interested in this PR, but in case you are:

What I would be curious about is a more concrete use-case that you may have in mind. E.g. writing an application (or library) that uses generics-eot to implement for example json serialization. And some examples on why it would be bad without type-level names and how it could be better if we had them. Without that it's a bit theoretic and hard to gauge the benefits and requirements for adding type-level field names.

[pkamenarsky]

Hey, not a problem!

I can give you something better than a theoretical use case: knit is a library I'm using in production and you can see here that type-level field names are necessary to look up the referenced type of a record id. I'm not sure how this would be possible without type-level names.

That said, since generics-eot is pretty small in scope and probably not going to change much, if at all, and since I'm just distributing the type-level version directly with knit, I don't think it's super necessary to merge this PR. If it turns out it's useful for other use cases as well I could upload a generics-eot-typelevel fork to Hackage in the future.

[soenkehahn]

knit looks awesome!

That said, since generics-eot is pretty small in scope and probably not going to change much, if at all, and since I'm just distributing the type-level version directly with knit, I don't think it's super necessary to merge this PR. If it turns out it's useful for other use cases as well I could upload a generics-eot-typelevel fork to Hackage in the future.

Yeah, that sounds good. Especially given how unresponsive I seem to be for this package right now. (Sorry about that, again!) I came up with this PR to give users a better chance to find your fork: #28. Reviews very much appreciated! I would then close this PR here if that's good with you.

[pkamenarsky]

Sounds good, and the PR looks good to me!