search

phadej / staged-gg

Staged GHC.Generics
BSD 3-Clause "New" or "Revised" License
4 stars 1 forks source link

Add Generic generics #5

Open treeowl opened 2 years ago

treeowl commented 2 years ago

Add functions genericTo and genericFrom that use GHC Generics to implement the Generic methods.

treeowl commented 2 years ago

A couple questions:

  1. What should I name the module and functions?
  2. Should I add GHC.Generic default methods to Generic? That would seem to match the default Rep definition rather nicely.

I verified that the functions produce compilable code by using them in the Instances module for the types there that have GHC.Generics instances. Unfortunately, the resulting compilation time was much worse, so I didn't commit those changes.

phadej commented 2 years ago

It's cool that this is possible, but it's also awful.

The idea of staged generics is to be 100% that the generic representation isn't present at the run time. This code invalidates that property: we are back to relying on optimizer.

phadej commented 2 years ago

Sorry, I misunderstood what this tries to do.

phadej commented 2 years ago

Should I add GHC.Generic default methods to Generic? That would seem to match the default Rep definition rather nicely.

Yes, that would be great. I feel silly for not trying this to begin with!

What should I name the module and functions?

GHC.Staged.Generics.Generic makes some sense, and the pun just makes it better.

genericTo and genericFrom are fine function names, IMO. (e.g. generics-sop has gto and gfrom for GHC -> SOP, these are fine too, but i'd prefer longer names).

treeowl commented 2 years ago

I reset to your branch and made a few changes. I left the kinds of the representation types as you had changed them, but I'm not clear on why you want q to be completely polykinded, rather than z -> Type.

phadej commented 2 years ago

If stuff works without that generalization patch, just drop it.

treeowl commented 2 years ago

If stuff works without that generalization patch, just drop it.

I dropped it. It likely would make sense to generalize somewhat, but that wouldn't allow a minor release with the generic stuff as it is right now, and I'm not sure exactly how far to generalize. Some options:

  1. y -> Type
  2. y -> TYPE r
  3. y -> z
  4. z ~ (Arg z -> Res z) => z (I think this is possible...)
  5. z

I don't have much intuition for which of these makes the most sense from a utility and ergonomic standpoint.

treeowl commented 2 years ago

Oh, I guess I was supposed to rename the GHCGenerically module, make it public, and export the generic functions from there. And I guess also add a GRep type synonym. Not sure if any of that should be exported by the main module.

googleson78 commented 2 years ago

As someone who is not too much into GHC.Generic and especially not that informed about staged generics, can I ask (if you have the time to answer) - what does this bring? Easier usage of staged-gg, since now whenever you have deriving stock Generic you can get staged-ggs Generic? And does it still guarantee that the intermediate representation will still all be eliminated? (or am I entirely misunderstanding what this pr does?)

treeowl commented 2 years ago

@googleson78, exactly. I've never actually used this package, but with similarish classes it can be very useful to be able to instantiate the class without actually splicing in any Template Haskell. Using a top level splice breaks up the module, with all sorts of potential annoying complications. The generated code should be identical, modulo alpha conversion. The new mechanism just lets you generate the splices using GHC generics if you want.