Derive superclasses automatically if possible

changed weight to 5

added Tfeature request Trac import labels

This proposal shares many similarities with the IntrinsicSuperclasses and InstanceTemplates proposals, so I'll link them here. However, this proposal shares many of their downsides, which I'll briefly expound upon here.

First, there's the technical challenges to this proposal. Not all instances are made equal, and deriving exposes this in many ways. For instance, suppose you tried this under your proposal:

class Traversable f => Witherable f where ...

newtype Wrapped f a = Wrap (f a)
  deriving newtype Witherable

This would attempt the following:

deriving newtype instance Functor f => Functor (Wrapped f)
deriving newtype instance Foldable f => Foldable (Wrapped f)
deriving newtype instance Traversable f => Traversable (Wrapped f)
deriving newtype instance Witherable f => Witherable (Wrapped f)

But trying to derive Traversable that way will fail, as it is ill-roled! See #13153. So not only would this throw an error, but it would throw an error that talks about a completely different class than Witherable. Mysterious.

What's more, there's quite a number of ambiguities you'd have to deal with. For instance, what happens under your proposal in this scenario?

class Show a => MyShow a where ...

data Foo
  deriving newtype MyShow

instance Show Foo

Since Show is a superclass of MyShow, you might expect the deriving newtype MyShow clause to derive instance Show Foo as well. But there's already an instance Show Foo! So we'd either have to error here, or come up with a scheme for defaulting to existing instances when scenarios like the above one crop up.

You might respond: "But that's easy! Just use the existing Show Foo instance!" But it gets even hairier than that:

class Show a => MyShow1 a where ...
class Show a => MyShow2 a where ...

data Foo
  deriving newtype MyShow1
  deriving anyclass MyShow2

Now we must ask: which of the two deriving clauses will implicitly derive Show behind the scenes? The choice matters, because a newtype-derived Show instance will be completely different than an anyclass-derived one! If the answer to this question is "use the first deriving clause", then now the order in which you write deriving clauses matters, which is a property that Haskell has never had up to this point.

Finally, there's one more objection I will make not on technical grounds, but on aesthetic ones. This proposal would lose the property that all instances are explicitly asked for by the user. I (personally) find the idea of instances being snuck in behind the scenes quite shady and hard to reason about, and in addition, we'd lose things like concrete source locations for every instance, the ability to annotate all instances with Haddocks, etc.

So my opinion in that it's a huge amount of complexity for very little gain and many drawbacks. I like the idea of doing something like this in Template Haskell, so I'm glad that someone is pursuing this in #10607 (closed).

I figured there would be difficulties (newtypes causing trouble again via roles etc.), thanks for taking the time to respond. I'll continue thinking about this.

In the end it's only convenience.

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedWon'tFix

I added a module Data.Derive.Superclass in derive-package http://hackage.haskell.org/package/derive-topdown-0.0.2.0 which partially solve this problem.

`style="font-size: 80%"

{{{#!haskell

newtype IO_ a = IO_ (IO a) strategy_deriving_superclasses newtype_ ''MonadIO ''IO_

You will get:

strategy_deriving_superclasses newtype_ ''MonadIO ''IO_ ======> deriving newtype instance MonadIO IO_ deriving newtype instance Monad IO_ deriving newtype instance Applicative IO_ deriving newtype instance Functor IO_

Appearently, Functor f => Applicative f => Monad f => MonadIO f

newtype F32 = F32 Float newtype_deriving_superclasses ''RealFloat ''F32

You will get:

newtype_deriving_superclasses ''RealFloat ''F32 ======> deriving newtype instance RealFloat F32 deriving newtype instance RealFrac F32 deriving newtype instance Real F32 deriving newtype instance Num F32 deriving newtype instance Ord F32 deriving newtype instance Eq F32 deriving newtype instance Fractional F32 deriving newtype instance Floating F32 ` }}}

Please try the package, if there are problems with it, please contact with me.

added Pnormal label

Trac field	Value
Version	8.0.1
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

Derive superclasses automatically if possible

Child items 0

Activity