#13153: Several Traversable instances have an extra fmap -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, I see what you're getting at now. It's quite unfortunate that we have to go through such contortions to make applying the newtype constructor zero-cost. We certainly could change the `Traversable ZipList` implementation to what you suggest to avoid this quandary, but there's no getting around the fact that it's a hack. One thing I've contemplated for a while is adding an `unsafenewtype` deriving strategy that implements what Richard suggests in https://ghc.haskell.org/trac/ghc/ticket/9123#comment:27. That is, if you wrote: {{{#!hs {-# LANGUAGE DerivingStrategies #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} newtype ZipList a = ZipList [a] deriving newtype (Functor, Foldable) deriving unsafenewtype (Traversable) }}} Then the derived `Traversable ZipList` instance would be: {{{#!hs instance Traversable ZipList where traverse :: forall f a b. Applicative f => (a -> f b) -> ZipList a -> f (ZipList b) traverse = unsafeCoerce (traverse :: (a -> f b) -> [a] -> f [b]) }}} Granted, this is a separate hack to get around the fact that we don't have higher-kinded roles yet, but it's (IMO) much nicer to use than having to manually inline the definition of `traverse` like you demonstrated above. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13153#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler