ndmitchell
Example in Data.Derive.UniplateDirect fails
{-# OPTIONS_GHC -F -pgmFderive -optF-F -optF-F #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE MultiParamTypeClasses #-}
import Data.Derive.UniplateDirect
import Data.Generics.Uniplate.Direct
data Foo a = Foo a (Bool, a)
{-!
deriving instance UniplateDirect (Foo Int)
deriving instance UniplateDirect (Bool, Int) Int
deriving instance UniplateDirect (Foo Int) Int
!-}
When loaded or compiled:
λ> :load "/tmp/test.hs"
[ 1 of 1] Compiling Main ( /tmp/test.hs, interpreted )
/tmp/ghced76_0/ghc_11.hspp:17:10: error:
• Expecting one fewer argument to ‘Uniplate Foo’
Expected kind ‘* -> Constraint’,
but ‘Uniplate Foo’ has kind ‘Constraint’
• In the instance declaration for ‘Uniplate Foo Int’
/tmp/ghced76_0/ghc_11.hspp:17:19: error:
• Expecting one more argument to ‘Foo’
Expected a type, but ‘Foo’ has kind ‘* -> *’
• In the first argument of ‘Uniplate’, namely ‘Foo’
In the instance declaration for ‘Uniplate Foo Int’
/tmp/ghced76_0/ghc_11.hspp:25:10: error:
• Expecting one fewer argument to ‘Biplate Int Foo’
Expected kind ‘* -> Constraint’,
but ‘Biplate Int Foo’ has kind ‘Constraint’
• In the instance declaration for ‘Biplate Int Foo Int’
/tmp/ghced76_0/ghc_11.hspp:25:22: error:
• Expecting one more argument to ‘Foo’
Expected a type, but ‘Foo’ has kind ‘* -> *’
• In the second argument of ‘Biplate’, namely ‘Foo’
In the instance declaration for ‘Biplate Int Foo Int’
Failed, modules loaded: none.
Do you actually use UniplateDirect? I generally switched to Uniplate.Data for most of my programs, which has the advantage of no instances required. Doesn't sound too hard, but really looking for other people to fix it, as per #6 (which it seems you've already found).
I was looking for the option of using UniplateDirect because what I have now is incredibly slow. I will give the fix a shot, and if I can do it I will be more confident about taking on #6.
Have you read https://hackage.haskell.org/package/uniplate-1.6.12/docs/Data-Generics-Uniplate-Data.html, particularly the part about UNIPLATE_VERBOSE? Table computation can give a massive speed difference, so setting it to -1 is worthwhile to see if that's an initial issue.
Neil, do you know why loading Example.hs gives me
derive: Don't know how to derive type class: Eq
Yep, in the last release I ripped out everything GHC could derive itself on the basis people should use GHC in preference to derive and I could avoid porting those definitions to the new Haskell-src-exts library. I suspect I didn't update the example.
Lately I've become leery of GHC.Generics - it creates huge declarations when there are a lot of constructors, and the results take a long time to compile.
I meant that Eq is baked into the compiler, not just that it could be done using Generics. That said, a Generic solution while taking a long time to compile is often to be preferred to a preprocessor.
On the other hand, I just eliminated all the Generic instances from our GHCJS application (using custom implementations of deriveSerialize and deriveJSON instead) and the javascript executable size dropped from 52M to 36M. I wonder if there will be a performance hit?