#12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12980 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): An exhaustive search through `ghc-prim` and `base` found 34 (!) classes that can be generalized this way: {{{ Eq, Ord, Functor, Applicative, Monad, MonadFail, MonadFix, MonadIO, Bifoldable, Bifunctor, HasResolution, Foldable, Eq1, Ord1, Eq2, Ord2, IsString, TestCoercion, TestEquality, Storable, IsList, Num, Real, Fractional, Generic, Generic1, GHCiSandboxIO, BufferedIO, RawIO, IsLabel, PrintfType, HPrintfType, PrintfArg, IsChar }}} Some are surely more useful to generalize than others. But wow! More classes morally could be included in this list but for two limiting factors: - Many classes use lists somewhere. (For example, `Show`.) However, we could define a family of list types, one for each representation (which would box unboxed tuples), and then use a type family to select the appropriate list type, allowing generalizations of classes that use lists. - Several classes (e.g., `Integral`) use tuples, preventing generalization. But we could just use unboxed tuples and away we go. Another annoyance was that `Applicative` can be generalized to make its parameter `f :: Type -> TYPE r`, but not `f :: TYPE r1 -> TYPE r2`. The latter is impossible because the class definition mentions `f (a -> b)`, and functions are always lifted. It would be lovely, though, to ponder the possibility of `class Applicative (f :: forall (r1 :: RuntimeRep). TYPE r1 -> TYPE r2)`, where `Applicative` would then have a higher-rank kind. And, we could generalize `IO` (it's implemented using an unboxed tuple, after all) and then `IO` could be made an instance of this new `Applicative`. `Monad` would soon follow, and you'd then be able to return unboxed values in `do`-notation. A final note: In testing all this, I had to add `default` signatures imposing a `r ~ LiftedRep` constraint whenever a generalized class had a default implementation, because the default implementation would work only at kind `Type`. This works, but it's disappointing that there can be no defaults at representations other than `LiftedRep`. However, I've realized we ''can''. Instead of `r ~ LiftedRep` in the `default` signature, impose a `Typeable r` constraint. Then we can do a runtime type test to figure out the representation and to squash the levity polymorphism. (This actually works.) A sufficiently smart compiler would be able to optimize away the runtime type test in any non-levity-polymorphic class instance. And we're just left with happiness and a wicked powerful type system. My (rushed, somewhat shoddy) work on this is [https://github.com/goldfirere/ghc/tree/lev-poly-base here]. I don't expect that to ever be merged -- I just was exploring the possibility. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12708#comment:29 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler