At the moment every part of the GHC AST derives instances of Data and Typeable. There are no instances of Generic. If I try to standalone derive these, the derivation eventually fails for deriving instance Generic (Name) because the constructors are not all in scope. So, does it make sense in GHC to at least derive Generic for the items that are opaque, and at most to do so for the whole AST. I know there were some concerns earlier about too many instances being derived, and its impact on compilation time and memory, so the minimal version may be best. This will allow the new generation libraries built around Generics to perform on GHC data structures too. Alan
FYI I have created ghc-generic-instances on hackage as a cache of the derived instances. Name cannot have a Generic instance due to the unboxed type(s) in it. Alan On Wed, Jan 14, 2015 at 11:03 PM, Alan & Kim Zimmerman <alan.zimm@gmail.com> wrote:
At the moment every part of the GHC AST derives instances of Data and Typeable.
There are no instances of Generic.
If I try to standalone derive these, the derivation eventually fails for
deriving instance Generic (Name)
because the constructors are not all in scope.
So, does it make sense in GHC to at least derive Generic for the items that are opaque, and at most to do so for the whole AST.
I know there were some concerns earlier about too many instances being derived, and its impact on compilation time and memory, so the minimal version may be best.
This will allow the new generation libraries built around Generics to perform on GHC data structures too.
Alan
I have nothing against this. If the unboxed types are a problem for the automatic Generic derivation, a manual instance could be written instead. Cheers, Pedro On Wed, Jan 14, 2015 at 9:03 PM, Alan & Kim Zimmerman <alan.zimm@gmail.com> wrote:
At the moment every part of the GHC AST derives instances of Data and Typeable.
There are no instances of Generic.
If I try to standalone derive these, the derivation eventually fails for
deriving instance Generic (Name)
because the constructors are not all in scope.
So, does it make sense in GHC to at least derive Generic for the items that are opaque, and at most to do so for the whole AST.
I know there were some concerns earlier about too many instances being derived, and its impact on compilation time and memory, so the minimal version may be best.
This will allow the new generation libraries built around Generics to perform on GHC data structures too.
Alan
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Hi Pedro That makes sense. I hit a mental block as to how to turn the generic representation back into the original type, but obviously if you know what you want to turn it into, the type-specific instance will be used. Alan On Fri, Feb 6, 2015 at 11:58 AM, José Pedro Magalhães <dreixel@gmail.com> wrote:
I have nothing against this.
If the unboxed types are a problem for the automatic Generic derivation, a manual instance could be written instead.
Cheers, Pedro
On Wed, Jan 14, 2015 at 9:03 PM, Alan & Kim Zimmerman <alan.zimm@gmail.com
wrote:
At the moment every part of the GHC AST derives instances of Data and Typeable.
There are no instances of Generic.
If I try to standalone derive these, the derivation eventually fails for
deriving instance Generic (Name)
because the constructors are not all in scope.
So, does it make sense in GHC to at least derive Generic for the items that are opaque, and at most to do so for the whole AST.
I know there were some concerns earlier about too many instances being derived, and its impact on compilation time and memory, so the minimal version may be best.
This will allow the new generation libraries built around Generics to perform on GHC data structures too.
Alan
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
participants (2)
-
Alan & Kim Zimmerman -
José Pedro Magalhães