November 2003 - template-haskell

Big TH commit
by Simon Peyton-Jones 18 Dec '03

18 Dec '03

OK, I've committed the new TH stuff. There is still more to do, but lots of stuff works that didn't before (summarised below). One thing that's a bit "off" at the moment is that I'm using the type checker's own monad to generate uniques for TH. As a result, if you print out the TH-generated code, you get stuff like data TH_reifyDecl1.R a_1627393116 = TH_reifyDecl1.C a_1627393116 Now there's nothing wrong with this, but it might make sense for the pretty-printer (now in THLib) to clean it up. I'm hoping that Ian or someone will do that task -- it's quite clearly separated. Meanwhile, please do beat on this new stuff. It's really a big step forward I think. Simon -----Original Message----- From: cvs-all-bounces(a)haskell.org [mailto:cvs-all-bounces@haskell.org] On Behalf Of Simon Peyton Jones Sent: 06 November 2003 17:10 To: cvs-ghc(a)haskell.org; cvs-fptools(a)haskell.org; cvs-libraries(a)haskell.org Subject: cvs commit: fptools/ghc/compiler/basicTypes Name.lhs OccName.lhs RdrName.lhs UniqSupply.lhs Unique.lhs Var.lhs fptools/ghc/compiler/deSugar DsExpr.lhs DsForeign.lhs DsMeta.hs DsMonad.lhs fptools/ghc/compiler/hsSyn Convert.lhs HsExpr.lhs ... simonpj 2003/11/06 09:10:01 PST Modified files: ghc/compiler/basicTypes Name.lhs OccName.lhs RdrName.lhs UniqSupply.lhs Unique.lhs Var.lhs ghc/compiler/deSugar DsExpr.lhs DsForeign.lhs DsMeta.hs DsMonad.lhs ghc/compiler/hsSyn Convert.lhs HsExpr.lhs ghc/compiler/iface LoadIface.lhs ghc/compiler/main ErrUtils.lhs ghc/compiler/parser Lexer.x Parser.y ghc/compiler/prelude PrelNames.lhs ghc/compiler/rename RnEnv.lhs RnExpr.lhs RnSource.lhs ghc/compiler/typecheck TcClassDcl.lhs TcExpr.lhs TcHsSyn.lhs TcHsType.lhs TcRnDriver.lhs TcRnMonad.lhs TcSplice.lhs TcUnify.lhs ghc/compiler/utils UniqFM.lhs testsuite/tests/ghc-regress/th TH_bracket3.hs TH_reifyDecl1.hs TH_reifyType1.hs TH_reifyType2.hs TH_repE1.hs TH_repE2.hs TH_repE3.hs TH_repPrim.hs TH_repPrim.stderr TH_repPrimOutput.hs TH_spliceDecl1.hs TH_spliceDecl2.hs TH_spliceDecl3.hs TH_spliceDecl3_Lib.hs TH_spliceE3.hs TH_spliceExpr1.hs all.T libraries/haskell-src Makefile Added files: testsuite/tests/ghc-regress/th TH_reifyDecl1.stderr TH_spliceE1.hs TH_spliceE1.stdout libraries/haskell-src/Language/Haskell TH.hs libraries/haskell-src/Language/Haskell/TH THLib.hs THSyntax.hs Removed files: testsuite/tests/ghc-regress/th TH_reifyDecl2.hs TH_reifyDecl3.hs TH_reifyDecl4.hs libraries/haskell-src/Language/Haskell THSyntax.hs Log: ------------------------------------ Major increment for Template Haskell ------------------------------------ 1. New abstract data type "Name" which appears where String used to be. E.g. data Exp = VarE Name | ... 2. New syntax 'x and ''T, for quoting Names. It's rather like [| x |] and [t| T |] respectively, except that a) it's non-monadic: 'x :: Name b) you get a Name not an Exp or Type 3. reify is an ordinary function reify :: Name -> Q Info New data type Info which tells what TH knows about Name 4. Local variables work properly. So this works now (crashed before): f x = $( [| x |] ) 5. THSyntax is split up into three modules: Language.Haskell.TH TH "clients" import this Language.Haskell.TH.THSyntax data type declarations and internal stuff Language.Haskell.TH.THLib Support library code (all re-exported by TH), including smart constructors and pretty printer 6. Error reporting and recovery are in (not yet well tested) report :: Bool {- True <=> fatal -} -> String -> Q () recover :: Q a -> Q a -> Q a 7. Can find current module currentModule :: Q String Much other cleaning up, needless to say. Revision Changes Path 1.107 +1 -1 fptools/ghc/compiler/basicTypes/Name.lhs 1.56 +10 -4 fptools/ghc/compiler/basicTypes/OccName.lhs 1.26 +3 -3 fptools/ghc/compiler/basicTypes/RdrName.lhs 1.32 +2 -2 fptools/ghc/compiler/basicTypes/UniqSupply.lhs 1.69 +11 -8 fptools/ghc/compiler/basicTypes/Unique.lhs 1.33 +8 -8 fptools/ghc/compiler/basicTypes/Var.lhs 1.103 +1 -2 fptools/ghc/compiler/deSugar/DsExpr.lhs 1.81 +2 -2 fptools/ghc/compiler/deSugar/DsForeign.lhs 1.48 +318 -296 fptools/ghc/compiler/deSugar/DsMeta.hs 1.51 +4 -2 fptools/ghc/compiler/deSugar/DsMonad.lhs 1.41 +79 -74 fptools/ghc/compiler/hsSyn/Convert.lhs 1.88 +0 -19 fptools/ghc/compiler/hsSyn/HsExpr.lhs 1.5 +1 -1 fptools/ghc/compiler/iface/LoadIface.lhs 1.42 +2 -10 fptools/ghc/compiler/main/ErrUtils.lhs 1.15 +61 -31 fptools/ghc/compiler/parser/Lexer.x 1.129 +9 -13 fptools/ghc/compiler/parser/Parser.y 1.83 +0 -3 fptools/ghc/compiler/prelude/PrelNames.lhs 1.171 +18 -22 fptools/ghc/compiler/rename/RnEnv.lhs 1.125 +2 -6 fptools/ghc/compiler/rename/RnExpr.lhs 1.162 +3 -0 fptools/ghc/compiler/rename/RnSource.lhs 1.137 +1 -1 fptools/ghc/compiler/typecheck/TcClassDcl.lhs 1.161 +0 -12 fptools/ghc/compiler/typecheck/TcExpr.lhs 1.94 +0 -2 fptools/ghc/compiler/typecheck/TcHsSyn.lhs 1.7 +1 -3 fptools/ghc/compiler/typecheck/TcHsType.lhs 1.53 +1 -0 fptools/ghc/compiler/typecheck/TcRnDriver.lhs 1.28 +5 -2 fptools/ghc/compiler/typecheck/TcRnMonad.lhs 1.28 +232 -120 fptools/ghc/compiler/typecheck/TcSplice.lhs 1.52 +1 -1 fptools/ghc/compiler/typecheck/TcUnify.lhs 1.37 +16 -16 fptools/ghc/compiler/utils/UniqFM.lhs 1.2 +1 -0 fptools/testsuite/tests/ghc-regress/th/TH_bracket3.hs 1.4 +30 -14 fptools/testsuite/tests/ghc-regress/th/TH_reifyDecl1.hs 1.4 +3 -3 fptools/testsuite/tests/ghc-regress/th/TH_reifyType1.hs 1.4 +3 -3 fptools/testsuite/tests/ghc-regress/th/TH_reifyType2.hs 1.3 +1 -1 fptools/testsuite/tests/ghc-regress/th/TH_repE1.hs 1.2 +1 -1 fptools/testsuite/tests/ghc-regress/th/TH_repE2.hs 1.2 +1 -1 fptools/testsuite/tests/ghc-regress/th/TH_repE3.hs 1.4 +11 -12 fptools/testsuite/tests/ghc-regress/th/TH_repPrim.hs 1.4 +6 -6 fptools/testsuite/tests/ghc-regress/th/TH_repPrim.stderr 1.5 +2 -10 fptools/testsuite/tests/ghc-regress/th/TH_repPrimOutput.hs 1.5 +2 -2 fptools/testsuite/tests/ghc-regress/th/TH_spliceDecl1.hs 1.3 +1 -2 fptools/testsuite/tests/ghc-regress/th/TH_spliceDecl2.hs 1.3 +2 -2 fptools/testsuite/tests/ghc-regress/th/TH_spliceDecl3.hs 1.5 +4 -4 fptools/testsuite/tests/ghc-regress/th/TH_spliceDecl3_Lib.hs 1.2 +1 -1 fptools/testsuite/tests/ghc-regress/th/TH_spliceE3.hs 1.3 +1 -1 fptools/testsuite/tests/ghc-regress/th/TH_spliceExpr1.hs 1.15 +3 -4 fptools/testsuite/tests/ghc-regress/th/all.T 1.9 +2 -2 fptools/libraries/haskell-src/Makefile _______________________________________________ Cvs-libraries mailing list Cvs-libraries(a)haskell.org http://www.haskell.org/mailman/listinfo/cvs-libraries

2 1

RE: Representing unboxed tuples in TH
by Simon Peyton-Jones 26 Nov '03

26 Nov '03

Only that the more one adds to THSyntax the more any program running over it needs to deal with. Functional dependencies? scoped type variables? etc S | -----Original Message----- | From: Sean Seefried [mailto:sseefried@cse.unsw.edu.au] | Sent: 26 November 2003 09:56 | To: template-haskell(a)haskell.org | Cc: Simon Peyton-Jones | Subject: Representing unboxed tuples in TH | | I've noticed that you can't represent unboxed tuples in Template | Haskell. Is there any strong reason for why this would be hard to do? | My knowledge on this topic is scant. | | Sean |

1 0

Representing unboxed tuples in TH
by Sean Seefried 26 Nov '03

26 Nov '03

I've noticed that you can't represent unboxed tuples in Template Haskell. Is there any strong reason for why this would be hard to do? My knowledge on this topic is scant. Sean

1 0

RE: [Template-haskell] TH Module names
by Simon Peyton-Jones 21 Nov '03

21 Nov '03

Yes, in the HEAD it's already spit into Language.Haskell.TH Language.Haskell.TH.THSyntax Language.Haskell.TH.THLib Perhaps I should change "THSyntax" to "Syntax" and similarly for Lib. Seems like a good plan. At the moment, Lib contains the pretty printer, but maybe I should split that off too. Does anyone else have opinions about this? Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Tomasz Zielonka | Sent: 20 November 2003 23:28 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] TH Module names | | Hello! | | How about renaming | Language.Haskell.THSyntax | to | Language.Haskell.TH.Syntax | | Then we could split this module into smaller ones, like: | | Language.Haskell.TH.Syntax | Language.Haskell.TH.Pretty | Language.Haskell.TH.UsefulHelperFunction (or something shorter) | ... | | I think it is nicer and would be helpful when experimenting in GHCi. | With the current big module when I do | :browse Language.Haskell.THSyntax | I get 7 screens of declarations (would be 9 screens on 25 line | terminal). | | Of course you can keep the old module and reimport the new modules from | it. | | Best regards, | Tom | | PS. TH saved me a big amount of tedious, bug-prone work. Thanks! :) | | -- | .signature: Too many levels of symbolic links | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

TH Module names
by Tomasz Zielonka 20 Nov '03

20 Nov '03

Hello! How about renaming Language.Haskell.THSyntax to Language.Haskell.TH.Syntax Then we could split this module into smaller ones, like: Language.Haskell.TH.Syntax Language.Haskell.TH.Pretty Language.Haskell.TH.UsefulHelperFunction (or something shorter) ... I think it is nicer and would be helpful when experimenting in GHCi. With the current big module when I do :browse Language.Haskell.THSyntax I get 7 screens of declarations (would be 9 screens on 25 line terminal). Of course you can keep the old module and reimport the new modules from it. Best regards, Tom PS. TH saved me a big amount of tedious, bug-prone work. Thanks! :) -- .signature: Too many levels of symbolic links

1 0

RE: Aggressive inlining
by Simon Peyton-Jones 20 Nov '03

20 Nov '03

Sounds as if you might need Template Haskell http://research.microsoft.com/~simonpj/papers/meta-haskell/ Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Blue | Steel | Sent: 19 November 2003 22:43 | To: haskell-cafe(a)haskell.org | Subject: Aggressive inlining | | I'm working on a parlor trick. | | I would like to solve a 3-SAT problem at compile time, | so that the executable is super fast. | | Consider | --------------------------------------------------- | formula (x1,x2,x3) = (x1 || x2) && x3 | | tf = [True, False] | | assignments = [(x1,x2,x3)|x1<-tf,x2<-tf,x3<-tf] | | solutions = filter formula assignments | | main = do print solutions | --------------------------------------------------- | | Theoretically, a compiler could optimize this to | --------------------------------------------------- | main = do print [(True,True,True),...] | --------------------------------------------------- | | Is this actually possible in GHC? I've played with | inline pragmas and looked at -ddump-..., but I haven't | made much progress. | | Of course, the goal is to replace "formula" with a | formula that takes a 30-tuple instead of a triple and | really let GHC crank. | | Thanks for any help. | | | __________________________________ | Do you Yahoo!? | Protect your identity with Yahoo! Mail AddressGuard | http://antispam.yahoo.com/whatsnewfree | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: Reification in TH
by Simon Peyton-Jones 19 Nov '03

19 Nov '03

| I've played around with reifying types and found that one can only | reify names that have the following format: | | Name occ (NameG th_ns mod) Well that's just a bug. It's supposed to be possible to do f x = $(do { ... reify 'x .... }) modulo the caveats about how much of x's type will be visible by then. I'll fix that shortly. Meanwhile you want something more ambitious that I don't understand yet. | I might have a block of declarations like this | | ds = [d| f = .... | g x = f .... x.... | |] | | It would be extra nice if I could reify the type of "x" in the | following code. What do you mean by "in the following code"? You can't mean ds = [d| f = .... g x = f .... x.... |] w = do { reify 'x ... because x isn't in scope there. And even if you say w = do { reify (mkName "x")... } you'll get a dynamic error because x isn't in scope. So I really don't know what you mean. Perhaps what you mean is: let the Exp data structure be able to represent type-annotated terms when [| ... |] constructs a data structure, let it be replete with type annotations provide a way to look at these type annotations when taking the data structure apart I have thought about this a bit in the past, and it's tricky. An obvious place to attach type annotations would be to put the Type of a Name inside the Name. So you can say nameType :: Name -> Type to get the type of a variable. (Presumably it'd fail if given the Name of a type constructor or class.) But when the programmer constructs a Name with newName or mkName, he doesn't want to supply a type. So sometimes an Exp will have type-annotated Names and sometimes not. And there's still the ever present aspect of only having *partial* type information. (More tiresomely, GHC adds lots of crud -- dictionary applications and abstractions etc -- to the typechecked term, so it's not entirely easy to get back to the original term. But that part must be soluble.) Simon Of course the problem is that we don't even know if | "f" (or "g" for that matter) is going to type check until we've spliced | it. So we can only reify "x"'s type at splice time. | | I need the ability to reify "x"'s type and then, based on the | information I get back, transform the block of declarations, "ds", in a | certain manner. | So I would in effect be doing a kind of "speculative splice". But a | splice of top-level declarations can only occur at the top level! What | I'm suggesting would be a speculative splice inside the body of a | function, something that will ONLY work when the DecQ that we are | splicing only contains Names that refer to functions in other modules | or within the DecQ. (That is, we can't have the functions referring to | variables outside the DecQ but in the current module!). Fortunately, | this condition is satisfied by the DecQs I wish to do reification in. | | I can understand why no one would want to write a "reify" function as | described above. | | But the only reason I've been throwing functions in [d| |] brackets is | because I can't reify entire modules. (We would have to bloat .hi files | for this to be the case.) But, say this were possible. Then it would | be MUCH easier to code a reify function that could return the types of | local Names, because we would already known that the module which we | are reifying type checks and then in the bloated .hi files we could | simple annotate each occurrence of a Name with its type. This would be | extremely useful to me. | | Cheers, | | Sean |

1 0

PS to Names
by Simon Peyton-Jones 19 Nov '03

19 Nov '03

PS: the proposal of my previous message would also fix this (taken from the data decl of Exp) | InfixE (Maybe Exp) Exp (Maybe Exp) -- {x + y} or {(x+)} or {(+ x)} or {(+)} -- It's a bit gruesome to use an Exp as the -- operator, but how else can we distinguish -- constructors from non-constructors? -- Maybe there should be a var-or-con type? -- Or maybe we should leave it to the String itself? Now the operator can be just a Name. I'm even keener. Simon

1 0

Namespaces
by Simon Peyton-Jones 19 Nov '03

19 Nov '03

Template Haskellers Consider this reify (mkName "T") Do we get the data constructor T or the type constructor T? For in-scope top-level things we can say reify 'T reify ''T to distinguish, but currently there's no way to distinguish for dynamically scoped names built with mkName. Clearly a global Name, one made by 'T or ''T, keeps track of its own name space. An obvious possibility would be to make all Names do so. So then one would have mkVName :: String -> Name -- variables and data constructors mkTName :: String -> Name -- types, classes, and type variables Dually, one could have name-space predicates isVarName, isDcName, isTcName, isTvName :: Name -> Bool which said if a Name described a variable, datacon, tycoon, tyvar repectively. (mkVName would use the capitalisation convention to decide whether the Name was a datacon or a variable; similarly mkTName.) One advantage of this is that we could get rid of the VarE/ConE distinction, and the VarT/ConT distinction, which would be quite worthwhile, I think. And it would fix the problem I started this message with. But it would mean that the (hopefully few) mkName calls would need to change to mkVName and mkTName. I'm inclined to do this. Any comments? Simon

1 0

Reification in TH
by Sean Seefried 19 Nov '03

19 Nov '03

Hi Simon and fellow TH users, > Have the TH s you mentioned in your communities report now been fixed? I've played around with reifying types and found that one can only reify names that have the following format: Name occ (NameG th_ns mod) which means that it's not possible to reify the Name "x" in the following expression: \x -> x + 3 since it is local. I realise that implementing such reification is a whole new can of worms. I'll give you an idea of what I want and then you can tell me whether it's infeasible or not. I might have a block of declarations like this ds = [d| f = .... g x = f .... x.... |] It would be extra nice if I could reify the type of "x" in the following code. Of course the problem is that we don't even know if "f" (or "g" for that matter) is going to type check until we've spliced it. So we can only reify "x"'s type at splice time. I need the ability to reify "x"'s type and then, based on the information I get back, transform the block of declarations, "ds", in a certain manner. So I would in effect be doing a kind of "speculative splice". But a splice of top-level declarations can only occur at the top level! What I'm suggesting would be a speculative splice inside the body of a function, something that will ONLY work when the DecQ that we are splicing only contains Names that refer to functions in other modules or within the DecQ. (That is, we can't have the functions referring to variables outside the DecQ but in the current module!). Fortunately, this condition is satisfied by the DecQs I wish to do reification in. I can understand why no one would want to write a "reify" function as described above. But the only reason I've been throwing functions in [d| |] brackets is because I can't reify entire modules. (We would have to bloat .hi files for this to be the case.) But, say this were possible. Then it would be MUCH easier to code a reify function that could return the types of local Names, because we would already known that the module which we are reifying type checks and then in the bloated .hi files we could simple annotate each occurrence of a Name with its type. This would be extremely useful to me. Cheers, Sean

1 0