#4129: Template haskell API makes inconsistent use of [Q Dec], Q [Dec] and Q Dec
---------------------------------+------------------------------------------
Reporter: lilac | Owner:
Type: proposal | Status: new
Priority: normal | Milestone: Not GHC
Component: Template Haskell | Version: 6.12.1
Keywords: | Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Changes (by simonpj):
* milestone: => Not GHC
Comment:
This proposal makes perfect sense to me, but it's a ''library'' proposal
that will affect the TH API, and thereby break existing TH programs. So
the right thing is to use the library submission process to specify and
argue for the change
http://www.haskell.org/haskellwiki/Library_submissions. If you can get a
consensus for change, it's fine with me!
You don't really say which functions are involved in "all [DecQ]
arguments", but I think you mean mainly (or perhaps exclusively) the
"smart contructors", such as
{{{
Lib.hs:21:type DecQ = Q Dec
Lib.hs:105:letS :: [DecQ] -> StmtQ
Lib.hs:159:match :: PatQ -> BodyQ -> [DecQ] -> MatchQ
Lib.hs:166:clause :: [PatQ] -> BodyQ -> [DecQ] -> ClauseQ
Lib.hs:226:letE :: [DecQ] -> ExpQ -> ExpQ
Lib.hs:277:valD :: PatQ -> BodyQ -> [DecQ] -> DecQ
Lib.hs:285:funD :: Name -> [ClauseQ] -> DecQ
Lib.hs:291:tySynD :: Name -> [TyVarBndr] -> TypeQ -> DecQ
Lib.hs:294:dataD :: CxtQ -> Name -> [TyVarBndr] -> [ConQ] -> [Name] ->
DecQ
Lib.hs:301:newtypeD :: CxtQ -> Name -> [TyVarBndr] -> ConQ -> [Name] ->
DecQ
Lib.hs:308:classD :: CxtQ -> Name -> [TyVarBndr] -> [FunDep] -> [DecQ] ->
DecQ
Lib.hs:315:instanceD :: CxtQ -> TypeQ -> [DecQ] -> DecQ
Lib.hs:323:sigD :: Name -> TypeQ -> DecQ
Lib.hs:326:forImpD :: Callconv -> Safety -> String -> Name -> TypeQ ->
DecQ
Lib.hs:331:pragInlD :: Name -> InlineSpecQ -> DecQ
Lib.hs:337:pragSpecD :: Name -> TypeQ -> DecQ
Lib.hs:343:pragSpecInlD :: Name -> TypeQ -> InlineSpecQ -> DecQ
Lib.hs:350:familyNoKindD :: FamFlavour -> Name -> [TyVarBndr] -> DecQ
Lib.hs:353:familyKindD :: FamFlavour -> Name -> [TyVarBndr] -> Kind ->
DecQ
Lib.hs:356:dataInstD :: CxtQ -> Name -> [TypeQ] -> [ConQ] -> [Name] ->
DecQ
Lib.hs:364:newtypeInstD :: CxtQ -> Name -> [TypeQ] -> ConQ -> [Name] ->
DecQ
Lib.hs:372:tySynInstD :: Name -> [TypeQ] -> TypeQ -> DecQ
}}}
I suggest that you be 100% precise in your library proposal.
I'll leave this ticket open, but mark it "Not GHC".
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4129#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs