#15151: Better Interaction Between Specialization and GND -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What Andrew means is that the desired machine-code for `sortPeople` is bit-for-bit identical with that of `sortInt`; and the SPECIALISE pragma in `Sort.hs` has already made a nice specialised copy of the latter. He just wants to reuse it. Of course, the reason for creating the `PersonId` newtype might be precisely the have a ''different'' `Ord` instance that the underlying `Int` type. Then it would be wrong to use `sortInt`. But if the `Ord` instance is derived, esp via GND, then it ''is'' sound to use `sortInt`. I don't see an easy way to achieve exactly what you want. But there are two workarounds. * As you say, use INLINABLE on `sort`; and specialise (even with an explicit SPECIALISE pragma) in the module where `PersonId` is defined. * Define `sortPeople` like this {{{ sortPeople :: MutablePrimArray s PersonId -> MutablePrimArray s PersonId sortPeople = coerce (sort @Int) }}} The `sort @Int` will get the efficient specialised version you want; and the `coerce` will lift it to the type you want. And if you want GHC to use `sortPeople` you'd have to add {{{ {-# RULES "sort/PersonId" sort @PersonId = sortPeople #-} }}} Interestingly, this would ''completely ignore'' any `Ord` instance for `PersonId`; indeed it doesn't need to have one. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15151#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler