Some look easy, some look like a type inference bug.
[1 of 3] Compiling Lens.Family.THCore ( Lens/Family/THCore.hs, .stack-work/dist/x86_64-osx/Cabal-1.24.0.0/build/Lens/Family/THCore.o )
/Users/danburton/github.com/DanBurton/lens-family-th/Lens/Family/THCore.hs:52:3: error:
• Ambiguous type variable ‘m2’ arising from a use of ‘return’
prevents the constraint ‘(Monad m2)’ from being solved.
Probable fix: use a type annotation to specify what ‘m2’ should be.
These potential instances exist:
instance Monad (Either e) -- Defined in ‘Data.Either’
instance Monad IO -- Defined in ‘GHC.Base’
instance Monad Q -- Defined in ‘Language.Haskell.TH.Syntax’
...plus four others
...plus 14 instances involving out-of-scope types
(use -fprint-potential-instances to see them all)
• In a stmt of a 'do' block:
return
$ case i of {
TyConI (DataD _ n ts _ _) -> (n, ts)
TyConI (NewtypeD _ n ts _ _) -> (n, ts)
_ -> error
$ "Can't derive Lens for: "
++ datatypeStr ++ ", type name required." }
In the expression:
do { let datatypeStr = nameBase datatype;
i <- reify datatype;
return
$ case i of {
TyConI (DataD _ n ts _ _) -> (n, ts)
TyConI (NewtypeD _ n ts _ _) -> (n, ts)
_ -> error
$ "Can't derive Lens for: "
++ datatypeStr ++ ", type name required." } }
In an equation for ‘extractLensTypeInfo’:
extractLensTypeInfo datatype
= do { let datatypeStr = ...;
i <- reify datatype;
return
$ case i of {
TyConI (DataD _ n ts _ _) -> ...
TyConI (NewtypeD _ n ts _ _) -> ...
_ -> error
$ "Can't derive Lens for: "
++ datatypeStr ++ ", type name required." } }
/Users/danburton/github.com/DanBurton/lens-family-th/Lens/Family/THCore.hs:53:13: error:
• The constructor ‘DataD’ should have 6 arguments, but has been given 5
• In the pattern: DataD _ n ts _ _
In the pattern: TyConI (DataD _ n ts _ _)
In a case alternative: TyConI (DataD _ n ts _ _) -> (n, ts)
/Users/danburton/github.com/DanBurton/lens-family-th/Lens/Family/THCore.hs:63:3: error:
• Ambiguous type variable ‘m1’ arising from a use of ‘return’
prevents the constraint ‘(Monad m1)’ from being solved.
Probable fix: use a type annotation to specify what ‘m1’ should be.
These potential instances exist:
instance Monad (Either e) -- Defined in ‘Data.Either’
instance Monad IO -- Defined in ‘GHC.Base’
instance Monad Q -- Defined in ‘Language.Haskell.TH.Syntax’
...plus four others
...plus 14 instances involving out-of-scope types
(use -fprint-potential-instances to see them all)
• In a stmt of a 'do' block:
return
$ case i of {
TyConI (DataD _ _ _ [RecC _ fs] _) -> fs
TyConI (NewtypeD _ _ _ (RecC _ fs) _) -> fs
TyConI (DataD _ _ _ [_] _)
-> error
$ "Can't derive Lens without record selectors: " ++ datatypeStr
TyConI (NewtypeD {})
-> error
$ "Can't derive Lens without record selectors: " ++ datatypeStr
TyConI (TySynD {})
-> error $ "Can't derive Lens for type synonym: " ++ datatypeStr
TyConI (DataD {})
-> error $ "Can't derive Lens for tagged union: " ++ datatypeStr
_ -> error
$ "Can't derive Lens for: "
++ datatypeStr ++ ", type name required." }
In the expression:
do { let datatypeStr = nameBase datatype;
i <- reify datatype;
return
$ case i of {
TyConI (DataD _ _ _ [RecC _ fs] _) -> fs
TyConI (NewtypeD _ _ _ (RecC _ fs) _) -> fs
TyConI (DataD _ _ _ [_] _)
-> error
$ "Can't derive Lens without record selectors: " ++ datatypeStr
TyConI (NewtypeD {})
-> error
$ "Can't derive Lens without record selectors: " ++ datatypeStr
TyConI (TySynD {})
-> error $ "Can't derive Lens for type synonym: " ++ datatypeStr
TyConI (DataD {})
-> error $ "Can't derive Lens for tagged union: " ++ datatypeStr
_ -> error
$ "Can't derive Lens for: "
++ datatypeStr ++ ", type name required." } }
In an equation for ‘extractConstructorFields’:
extractConstructorFields datatype
= do { let datatypeStr = ...;
i <- reify datatype;
return
$ case i of {
TyConI (DataD _ _ _ [RecC _ fs] _) -> fs
TyConI (NewtypeD _ _ _ (RecC _ fs) _) -> fs
TyConI (DataD _ _ _ [_] _)
-> error
$ "Can't derive Lens without record selectors: " ++ datatypeStr
TyConI (NewtypeD {})
-> error
$ "Can't derive Lens without record selectors: " ++ datatypeStr
TyConI (TySynD {})
-> error $ "Can't derive Lens for type synonym: " ++ datatypeStr
TyConI (DataD {})
-> error $ "Can't derive Lens for tagged union: " ++ datatypeStr
_ -> error
$ "Can't derive Lens for: "
++ datatypeStr ++ ", type name required." } }
/Users/danburton/github.com/DanBurton/lens-family-th/Lens/Family/THCore.hs:64:13: error:
• The constructor ‘DataD’ should have 6 arguments, but has been given 5
• In the pattern: DataD _ _ _ [RecC _ fs] _
In the pattern: TyConI (DataD _ _ _ [RecC _ fs] _)
In a case alternative: TyConI (DataD _ _ _ [RecC _ fs] _) -> fs
/Users/danburton/github.com/DanBurton/lens-family-th/Lens/Family/THCore.hs:134:3: error:
• Ambiguous type variable ‘m0’ arising from a use of ‘return’
prevents the constraint ‘(Monad m0)’ from being solved.
Probable fix: use a type annotation to specify what ‘m0’ should be.
These potential instances exist:
instance Monad (Either e) -- Defined in ‘Data.Either’
instance Monad IO -- Defined in ‘GHC.Base’
instance Monad Q -- Defined in ‘Language.Haskell.TH.Syntax’
...plus four others
...plus 14 instances involving out-of-scope types
(use -fprint-potential-instances to see them all)
• In a stmt of a 'do' block:
return
$ case i of {
TyConI (DataD _ _ _ fs _) -> fs
TyConI (NewtypeD _ _ _ f _) -> [f]
_ -> error $ "Can't derive traversal for: " ++ datatypeStr }
In the expression:
do { let datatypeStr = nameBase datatype;
i <- reify datatype;
return
$ case i of {
TyConI (DataD _ _ _ fs _) -> fs
TyConI (NewtypeD _ _ _ f _) -> [...]
_ -> error $ "Can't derive traversal for: " ++ datatypeStr } }
In an equation for ‘extractConstructorInfo’:
extractConstructorInfo datatype
= do { let datatypeStr = ...;
i <- reify datatype;
return
$ case i of {
TyConI (DataD _ _ _ fs _) -> fs
TyConI (NewtypeD _ _ _ f _) -> ...
_ -> error $ "Can't derive traversal for: " ++ datatypeStr } }
/Users/danburton/github.com/DanBurton/lens-family-th/Lens/Family/THCore.hs:135:13: error:
• The constructor ‘DataD’ should have 6 arguments, but has been given 5
• In the pattern: DataD _ _ _ fs _
In the pattern: TyConI (DataD _ _ _ fs _)
In a case alternative: TyConI (DataD _ _ _ fs _) -> fs
Some look easy, some look like a type inference bug.