#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

Reply via email to