Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#10512 closed feature request (wontfix)

Generic instances missing for Int32, Word64 etc.

Reported by: andreas.abel Owned by:
Priority: normal Milestone:
Component: Core Libraries Version: 7.10.1
Keywords: Generics Cc: core-libraries-committee@…, vagarenko, ekmett
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: #9526 Differential Rev(s):
Wiki Page:

Description

Some base types have Generic instances, like Integer, the machine-specific ones like Int32 have none. But these would be most useful when using generic Binary serialization.

I think it makes sense to add Generic instances for *all* primitive types in base.

I can define the instance myself, see https://github.com/agda/agda/commit/1d3710189989aced61be79c8e52945651fc94c0e

import GHC.Generics (Generic(..))
import qualified GHC.Generics as Gen

data D_Int32
data C_Int32

instance Gen.Datatype D_Int32 where
  datatypeName _ = "Int32"
  moduleName   _ = "GHC.Int32"
  -- packageName  _ = "base"

instance Gen.Constructor C_Int32 where
  conName _ = "" -- JPM: I'm not sure this is the right implementation...

instance Generic Int32 where
  type Rep Int32 = Gen.D1 D_Int32 (Gen.C1 C_Int32 (Gen.S1 Gen.NoSelector (Gen.Rec0 Int32)))
  from x = Gen.M1 (Gen.M1 (Gen.M1 (Gen.K1 x)))
  to (Gen.M1 (Gen.M1 (Gen.M1 (Gen.K1 x)))) = x

However, as GHC.Generics is a moving target, and changes over the compiler versions, I'd rather not have to.

Change History (12)

comment:1 Changed 3 years ago by ekmett

This'll be incredibly tedious, but it is the right thing to do.

comment:2 Changed 3 years ago by dreixel

I'm actually not too sure that this is the right thing to do. In fact, I've wondered if we shouldn't *remove* all the instances for base types altogether. They don't really add much, do they? Generic functions typically require ad-hoc instances for base types, so it doesn't help to have these instances. Perhaps the only reason is the meta-data...

comment:3 in reply to:  2 Changed 3 years ago by ekmett

In fact, I've wondered if we shouldn't *remove* all the instances for base types altogether.

Actually from talking to Eric Mertens on the topic I now agree.

The goal with generics is usually to get down to "leaves" that you know how to handle. This actively gets in the way of handling certain kinds of leaves.

comment:4 Changed 3 years ago by andreas.abel

All I know is that when I tried to generate the Binary instances for my data types, I got the complaint about missing Generic instances for Int32 and Word64. I might have asked for too many superclasses somewhere. At least Binary does not need Generic Int32 or Generic Word64. It is too late today to try to reconstruct my problem...

Last edited 3 years ago by andreas.abel (previous) (diff)

comment:5 Changed 3 years ago by rwbarton

Cc: vagarenko added

comment:6 Changed 3 years ago by thomie

Owner: ekmett deleted

comment:7 Changed 3 years ago by RyanGlScott

Cc: ekmett added

All I know is that when I tried to generate the Binary instances for my data types, I got the complaint about missing Generic instances for Int32 and Word64.

Really? I'm not sure why this would be the case, since in all of the examples I've seen, Generic instances don't require that a datatype's arguments also be Generic. For example, if you have this:

{-# LANGUAGE DeriveAnyClass, DeriveGeneric #-}
data T = T Int32 Word64 deriving (Binary, Generic)

Then the generic machinery in binary only requires that Int32 and Word64 be Binary instances.

Might I ask what your use case is? It seems very unlikely that we're going to be adding Generic instances for base types like these going forwards. In fact, we're going to remove the Generic instances for Char, Double, Float, and Int in GHC 8.0 for the reasons that Pedro and Ed described.

comment:8 Changed 3 years ago by simonpj

Keywords: Generics added

comment:9 Changed 3 years ago by RyanGlScott

Resolution: wontfix
Status: newclosed

I'm going to close this, since we have already moved in the direction of not providing Generic instances for primitive types with 700c42b5/ghc. Please re-open if you feel strongly otherwise.

comment:10 Changed 3 years ago by nh2

Note: In https://ghc.haskell.org/trac/ghc/ticket/9526#comment:13 RyanGlScott provided an explanation of why this change is no longer necessary.

comment:11 Changed 3 years ago by RyanGlScott

comment:12 Changed 2 years ago by Iceland_jack

Seems to break example from Generics.Deriving.Lens

ghci> allOf tinplate (=="Hello") (1::Int,2::Double,(),"Hello",["Hello"])

<interactive>:85:7: error:
    • No instance for (GHC.Generics.Generic Char)
        arising from a use of ‘tinplate’
    • In the first argument of ‘allOf’, namely ‘tinplate’
      In the expression:
        allOf
          tinplate
          (== "Hello")
          (1 :: Int, 2 :: Double, (), "Hello", ["Hello"])
      In an equation for ‘it’:
          it
            = allOf
                tinplate
                (== "Hello")
                (1 :: Int, 2 :: Double, (), "Hello", ["Hello"])
ghci> mapMOf_ tinplate putStrLn ("hello",[(2 :: Int, "world!")])

<interactive>:86:9: error:
    • No instance for (GHC.Generics.Generic Char)
        arising from a use of ‘tinplate’
    • In the first argument of ‘mapMOf_’, namely ‘tinplate’
      In the expression:
        mapMOf_ tinplate putStrLn ("hello", [(2 :: Int, "world!")])
      In an equation for ‘it’:
          it = mapMOf_ tinplate putStrLn ("hello", [(2 :: Int, "world!")])

Note: See TracTickets for help on using tickets.