From simonpj at microsoft.com Thu Nov 1 10:07:40 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Thu Nov 1 10:05:01 2007 Subject: [Template-haskell] Lift instances of the AST-related types In-Reply-To: <6a7c66fc0710291842obb218a8u7e26183b35e06e74@mail.gmail.com> References: <6a7c66fc0710291842obb218a8u7e26183b35e06e74@mail.gmail.com> Message-ID: Make a Trac feature request? As usual that doesn't guaranteed it'll get done, but it saves it getting forgotten. Using TH to generate the Lift instances seems like the right way to go -- it's what TH is for, and it's 95% as good as deriving( Lift ). Augmenting Ian's library so that when you got the library you thereby got the Lift instances (themselves generated by the library) for the TH data types. In that way the whole thing could be done by modifying Ian's library without touching GHC, which is always good. Simon | -----Original Message----- | From: template-haskell-bounces@haskell.org [mailto:template-haskell-bounces@haskell.org] On Behalf Of Alfonso | Acosta | Sent: 30 October 2007 01:43 | To: template-haskell@haskell.org | Subject: [Template-haskell] Lift instances of the AST-related types | | Hi, | | It has been suggested a few types in this list [1,2] that it would be | helpful to include a Lift instance of Exp, Type, Dec and friends. | | Having such instances allow to store the AST in a TH-generated | structure for later processing during runtime (something curcial in | the embedded compiler I'm currently developing). | | It would be great that the instances were included in the library | itself or if (even better) GHC supported automatic deriving of Lift. | | Until that happens, I have used a modified version Ian's th-lift[3] to | automatically generate the instances. | | Just in case anyone is interested, I attached the patch of th-lift and | the instantiation module. | | Cheers, | | Fons | | | [1] http://www.haskell.org/pipermail/template-haskell/2007-February/000593.html | [2] http://www.haskell.org/pipermail/template-haskell/2004-June/000289.html | [3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/th-lift-0.2 From alfonso.acosta at gmail.com Thu Nov 1 11:09:56 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Thu Nov 1 11:07:17 2007 Subject: [Template-haskell] Lift instances of the AST-related types In-Reply-To: References: <6a7c66fc0710291842obb218a8u7e26183b35e06e74@mail.gmail.com> Message-ID: <6a7c66fc0711010809r77c97c72pbe936fd6e7c411da@mail.gmail.com> Forgot to send this answer to the list, sorry. On 11/1/07, Simon Peyton-Jones wrote: > Make a Trac feature request? I'll be happy to do it. > Augmenting Ian's library so that when you got the library you thereby got the Lift instances (themselves generated by the library) for the TH data types. > > In that way the whole thing could be done by modifying Ian's library without touching GHC, which is always good. That's exactly what my patch+new module are supposed to do. I'm still waiting for Ian to review it and maybe include them in his library. Besides, since automatic instantiation of Lift seems to be a basic need for a TH programmer, Wouldn't it be a good idea to merge th-lift with the mainstream template-haskell library? Cheers, Fons From simonpj at microsoft.com Fri Nov 2 14:04:16 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Nov 2 14:01:35 2007 Subject: [Template-haskell] TupleT type constructor In-Reply-To: <20071029204400.GA18533@matrix.chaos.earth.li> References: <6a7c66fc0710290431l5b14e81w70649418360c88c7@mail.gmail.com> <20071029204400.GA18533@matrix.chaos.earth.li> Message-ID: | > I'm a bit confused about TupleT . Is is supposed to be only used when | > synthesizing types? (i.e. reify will never output such a type)? | | Quasiquotes produce it: | | Prelude Language.Haskell.TH> $( do t <- [t| (Int, Bool) |]; runIO $ print t; [| 1 |] ) | AppT (AppT (TupleT 2) (ConT GHC.Base.Int)) (ConT GHC.Base.Bool) | | > Should this be considered a bug or a feature? IMHO it's quite ugly to | > have two valid representations for the same type in the same AST | > structure. | | I wouldn't be opposed to removing it (in fact, I think there is a | general feeling that lots of redundancies in the TH syntax should be | removed, e.g. the subthread starting with | http://www.haskell.org/pipermail/template-haskell/2006-August/000572.html | but no-one has yet taken the lead and proposed something). I agree. As in: I would not be opposed to removing it. But we'd just need to be sure there was a convenient way of conjuring up the appropriate data constructor for an n-tuple. Simon From alfonso.acosta at gmail.com Fri Nov 2 14:44:57 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Fri Nov 2 14:42:25 2007 Subject: [Template-haskell] TupleT type constructor In-Reply-To: References: <6a7c66fc0710290431l5b14e81w70649418360c88c7@mail.gmail.com> <20071029204400.GA18533@matrix.chaos.earth.li> Message-ID: <6a7c66fc0711021144j186db884l4926689968083e02@mail.gmail.com> On 11/2/07, Simon Peyton-Jones wrote: > I agree. As in: I would not be opposed to removing it. But we'd just need to be sure there was a convenient way of conjuring up the appropriate data constructor for an n-tuple. TH.Syntax already provides: tupleTypeName :: Int -> Name tupleDataName :: Int -> Name IMHO, that should be enough From alfonso.acosta at gmail.com Fri Nov 2 18:36:47 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Fri Nov 2 18:34:03 2007 Subject: [Template-haskell] Obtaining the declaration of a variable name. Message-ID: <6a7c66fc0711021536n6587d07dr8a5db8a68cb9a92f@mail.gmail.com> Hi, The reification information of a variable is declared as: VarI Name Type (Maybe Dec) Fixity When I began using TH, I thought it was great to be able to retreive the declaration of a variable out of its name (it would have turned out to be pretty useful). However, after testing that reify returned Nothing all the time, I figured out I sadly couldn't count on that. That feature seems to be handy for my compiler again so I tried to guess what was wrong. According to Language.TH.Syntax: -- Nothing for lambda-bound variables, and -- for anything else TH can't figure out -- E.g. [| let x = 1 in $(do { d <- reify 'x; .. }) |] However, the typechecker (TcSplice module) always returns Nothing. So I guess it's simply not implemented. Am I missing something or should I add a feature request ticket? Thanks, Fons From alfonso.acosta at gmail.com Sat Nov 3 11:47:48 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Nov 3 11:45:02 2007 Subject: [Template-haskell] Lift instances of the AST-related types In-Reply-To: <6a7c66fc0711021224k2381cf10r54048ba1685d4c03@mail.gmail.com> References: <6a7c66fc0710291842obb218a8u7e26183b35e06e74@mail.gmail.com> <6a7c66fc0711010808t1ac295d0ybf47aeb3d4a1ab03@mail.gmail.com> <6a7c66fc0711021224k2381cf10r54048ba1685d4c03@mail.gmail.com> Message-ID: <6a7c66fc0711030847x4930cc9dt475278e8d24bf539@mail.gmail.com> This recent haskell-cafe thread[1] provides a way to implicity give support for automatic derivation of Lift in GHC. Since Data can be derived automatically and there's a way to lift any "Data a => a" it's like having automatic derivation for lift. It's not a substitute of Ian's package (the instace Data a => Lift a is illegal), but it complements it. What do you think about including a function like "liftData :: Data a => a -> ExpQ" in the library? On 11/2/07, Alfonso Acosta wrote: > On 11/2/07, Simon Peyton-Jones wrote: > > It'd be good to check that the Haddock docs for TH.Lift are in good shape. > > Well, right now they are inexistent but the library is tiny, that > shouldn't be a problem. > > > I'll leave this up to you two to finalise. > > Let's see what Ian thinks > > > (In fact it'd be great if you could improve the Haddock docs for the other TH modules. They are currently laughably bad. And you are clearly an expert!) > > I cannot agree more, when I began to use TH I was forced (and I keep > doing it) to look at the source comments to check what the AST-types > meant. > > I cannot promess anything for the short-term, but I'll try to send a > documentation patch at some point. > From alfonso.acosta at gmail.com Sat Nov 3 11:50:41 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sat Nov 3 11:47:55 2007 Subject: [Template-haskell] Lift instances of the AST-related types In-Reply-To: <6a7c66fc0711030847x4930cc9dt475278e8d24bf539@mail.gmail.com> References: <6a7c66fc0710291842obb218a8u7e26183b35e06e74@mail.gmail.com> <6a7c66fc0711010808t1ac295d0ybf47aeb3d4a1ab03@mail.gmail.com> <6a7c66fc0711021224k2381cf10r54048ba1685d4c03@mail.gmail.com> <6a7c66fc0711030847x4930cc9dt475278e8d24bf539@mail.gmail.com> Message-ID: <6a7c66fc0711030850t31725379x11ce360d1805f711@mail.gmail.com> Forgot to include the link to the aforementioned thread. [1] http://www.haskell.org/pipermail/haskell-cafe/2007-November/033955.html From igloo at earth.li Sat Nov 3 20:14:29 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 4 05:00:33 2007 Subject: [Template-haskell] Lift instances of the AST-related types In-Reply-To: <6a7c66fc0711030847x4930cc9dt475278e8d24bf539@mail.gmail.com> References: <6a7c66fc0710291842obb218a8u7e26183b35e06e74@mail.gmail.com> <6a7c66fc0711010808t1ac295d0ybf47aeb3d4a1ab03@mail.gmail.com> <6a7c66fc0711021224k2381cf10r54048ba1685d4c03@mail.gmail.com> <6a7c66fc0711030847x4930cc9dt475278e8d24bf539@mail.gmail.com> Message-ID: <20071104001429.GA28825@matrix.chaos.earth.li> On Sat, Nov 03, 2007 at 04:47:48PM +0100, Alfonso Acosta wrote: > > It's not a substitute of Ian's package (the instace Data a => Lift a > is illegal), but it complements it. You can have that instance with undecidable and overlapping instances, can't you? Or is there another problem I'm missing? Thanks Ian From igloo at earth.li Sat Nov 3 21:03:25 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Nov 4 05:00:41 2007 Subject: [Template-haskell] Obtaining the declaration of a variable name. In-Reply-To: <6a7c66fc0711021536n6587d07dr8a5db8a68cb9a92f@mail.gmail.com> References: <6a7c66fc0711021536n6587d07dr8a5db8a68cb9a92f@mail.gmail.com> Message-ID: <20071104010325.GB28825@matrix.chaos.earth.li> Hi Fons, On Fri, Nov 02, 2007 at 11:36:47PM +0100, Alfonso Acosta wrote: > > However, the typechecker (TcSplice module) always returns Nothing. So > I guess it's simply not implemented. > > Am I missing something or should I add a feature request ticket? If you are missing it then so am I. File away! I think the idea was that if it is in the same module then we should give you the Dec, but if it is in another module then we don't (we only have the interface file so we don't know what the source code was). We could also have a flag which means the source /is/ put in the interface file. I'm not sure how useful that would be, as the bootlibs would presumably not be compiled with it. Thanks Ian From alfonso.acosta at gmail.com Sun Nov 4 17:17:07 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sun Nov 4 17:14:19 2007 Subject: [Template-haskell] Extending the reification information of a class with its known instances Message-ID: <6a7c66fc0711041417m79a00ddes90daf139a16a3073@mail.gmail.com> Hi, I don't know whether this can be considered a generally desired feature, that's why I didn't create the ticket directly. I have to code a TH processing function, which, due to the untyped nature of the TH's AST, as it seems, would only be able to guarantee generating valid code if instance information of a class could be obtained. In my concrete case I have to, among other things, keep the AST of a function (for later processing by my embedded compiler) and it's value in Dynamic form (for later simulation of my embedded language). -- phantom parameter to guarantee type correctness newtype MyFun a = MyFun MyFunPrim data MyFunPrim = MyFun Name [Clause] Dynamic My TH constructor function has the type mkMyFun :: Q [Dec] -> ExpQ and a (naive) concrete example of use could be myFun1 :: MyFun (Bool -> Bool) myFun1 = $(mkMyFun [d| and :: Bool -> Bool and a b = a && b |]) The problem comes when generating the Dynamic value. There is no way to guarantee that the function. The only solutions I can think of to solve my problem are: a) The hard way: providing a catching mechanism badly generated code. b) The cleaner way: Providing a mechanism to check whether the function passed to mkMyFun is Typeable. something like isClassInstance :: Name -- ^ Class name -> Type -- ^ Type to check -> Bool (and maybe c) Hope for a new TH with a typed AST which could let me expess type constraints in declarations and expressions.) Right now, I can only expect the user to be nice and only supply Typeable functions. Cheers, Fons From alfonso.acosta at gmail.com Sun Nov 4 17:19:39 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Sun Nov 4 17:16:49 2007 Subject: [Template-haskell] Re: Extending the reification information of a class with its known instances In-Reply-To: <6a7c66fc0711041417m79a00ddes90daf139a16a3073@mail.gmail.com> References: <6a7c66fc0711041417m79a00ddes90daf139a16a3073@mail.gmail.com> Message-ID: <6a7c66fc0711041419l375cbab4h89829f3b57433abb@mail.gmail.com> On 11/4/07, Alfonso Acosta wrote: > The problem comes when generating the Dynamic value. There is no way > to guarantee that the function. I meant, "that the function is Typeable, sorry. I should get used to reread before posting. From simonpj at microsoft.com Mon Nov 5 04:18:37 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 5 04:15:46 2007 Subject: [Template-haskell] Obtaining the declaration of a variable name. In-Reply-To: <20071104010325.GB28825@matrix.chaos.earth.li> References: <6a7c66fc0711021536n6587d07dr8a5db8a68cb9a92f@mail.gmail.com> <20071104010325.GB28825@matrix.chaos.earth.li> Message-ID: Ian, Fons, I'll let the two of you agree the details. As to whether the Lift library should be in the GHC distribution, well I don't feel strongly. We are generally moving in the direction of putting less in the distribution, and making it easier to download and install supporting packages; but the TH package isn't big and I wouldn't object. Simon | -----Original Message----- | From: template-haskell-bounces@haskell.org [mailto:template-haskell-bounces@haskell.org] On Behalf Of Ian Lynagh | Sent: 04 November 2007 01:03 | To: Alfonso Acosta | Cc: template-haskell@haskell.org | Subject: Re: [Template-haskell] Obtaining the declaration of a variable name. | | | Hi Fons, | | On Fri, Nov 02, 2007 at 11:36:47PM +0100, Alfonso Acosta wrote: | > | > However, the typechecker (TcSplice module) always returns Nothing. So | > I guess it's simply not implemented. | > | > Am I missing something or should I add a feature request ticket? | | If you are missing it then so am I. File away! | | I think the idea was that if it is in the same module then we should | give you the Dec, but if it is in another module then we don't (we only | have the interface file so we don't know what the source code was). | | We could also have a flag which means the source /is/ put in the | interface file. I'm not sure how useful that would be, as the bootlibs | would presumably not be compiled with it. | | | Thanks | Ian | | _______________________________________________ | template-haskell mailing list | template-haskell@haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell From simonpj at microsoft.com Mon Nov 5 09:32:47 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Mon Nov 5 09:29:56 2007 Subject: [Template-haskell] Extending the reification information of a class with its known instances In-Reply-To: <6a7c66fc0711041417m79a00ddes90daf139a16a3073@mail.gmail.com> References: <6a7c66fc0711041417m79a00ddes90daf139a16a3073@mail.gmail.com> Message-ID: Reification is precisely supposed to allow you to ask the compiler about the current typing environment. In principle that could reasonably include the instance environment. It gets trickier if 'Type' contains type variables, because then it make a difference what local constraints are in scope. For example are we in the RHS of a function with type Num a => ..., in which case we have a Num dictionary available. But what if the current function has no type signature -- then we don't have declared dictionaries in scope. So I'm not sure what the Right Thing is. Create a feature request to hold the discussion, by all means, though. Simon | -----Original Message----- | From: template-haskell-bounces@haskell.org [mailto:template-haskell-bounces@haskell.org] On Behalf Of Alfonso | Acosta | Sent: 04 November 2007 22:17 | To: template-haskell@haskell.org | Subject: [Template-haskell] Extending the reification information of a class with its known instances | | Hi, | | I don't know whether this can be considered a generally desired | feature, that's why I didn't create the ticket directly. | | I have to code a TH processing function, which, due to the untyped | nature of the TH's AST, as it seems, would only be able to guarantee | generating valid code if instance information of a class could be | obtained. | | In my concrete case I have to, among other things, keep the AST of a | function (for later processing by my embedded compiler) and it's value | in Dynamic form (for later simulation of my embedded language). | | -- phantom parameter to guarantee type correctness | newtype MyFun a = MyFun MyFunPrim | | data MyFunPrim = MyFun Name [Clause] Dynamic | | My TH constructor function has the type | | mkMyFun :: Q [Dec] -> ExpQ | | and a (naive) concrete example of use could be | | myFun1 :: MyFun (Bool -> Bool) | myFun1 = $(mkMyFun [d| and :: Bool -> Bool | and a b = a && b |]) | | The problem comes when generating the Dynamic value. There is no way | to guarantee that the function is Typeable. | | The only solutions I can think of to solve my problem are: | | a) The hard way: providing a catching mechanism badly generated code. | b) The cleaner way: Providing a mechanism to check whether the | function passed to mkMyFun is Typeable. | | something like | | isClassInstance :: Name -- ^ Class name | -> Type -- ^ Type to check | -> Bool | | (and maybe c) Hope for a new TH with a typed AST which could let me | expess type constraints in declarations and expressions.) | | Right now, I can only expect the user to be nice and only supply | Typeable functions. | | Cheers, | | Fons | _______________________________________________ | template-haskell mailing list | template-haskell@haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell From alfonso.acosta at gmail.com Mon Nov 5 13:57:01 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon Nov 5 13:54:08 2007 Subject: [Template-haskell] TupleT type constructor In-Reply-To: <6a7c66fc0711021144j186db884l4926689968083e02@mail.gmail.com> References: <6a7c66fc0710290431l5b14e81w70649418360c88c7@mail.gmail.com> <20071029204400.GA18533@matrix.chaos.earth.li> <6a7c66fc0711021144j186db884l4926689968083e02@mail.gmail.com> Message-ID: <6a7c66fc0711051057h343d0596m84413d827616478b@mail.gmail.com> I've been thinking about it for a while and the special TupleT constructor still seems pretty useful. However, I think it should only be kept if there's a way to guarantee that reify is consistent with the definition of Type (i.e. it should alwa produce TupleT and not "ConT ''(,,,)" and friends ) Furthermore I would find it more appropiate to split Type into Constructors and Types themselves (just like it happens in Data.Typeable and Language.Haskell.Syntax) data Cons = Cons Name | SpecialCons data SpecialCons = Arrow | Tuple Int | List data Type = ForallT [Name] Cxt Type | VarT ConT Cons | AppT Type Type On 11/2/07, Alfonso Acosta wrote: > On 11/2/07, Simon Peyton-Jones wrote: > > I agree. As in: I would not be opposed to removing it. But we'd just need to be sure there was a convenient way of conjuring up the appropriate data constructor for an n-tuple. > > TH.Syntax already provides: > > tupleTypeName :: Int -> Name > tupleDataName :: Int -> Name > > IMHO, that should be enough > From alfonso.acosta at gmail.com Mon Nov 5 13:59:26 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Mon Nov 5 13:56:31 2007 Subject: [Template-haskell] TupleT type constructor In-Reply-To: <6a7c66fc0711051057h343d0596m84413d827616478b@mail.gmail.com> References: <6a7c66fc0710290431l5b14e81w70649418360c88c7@mail.gmail.com> <20071029204400.GA18533@matrix.chaos.earth.li> <6a7c66fc0711021144j186db884l4926689968083e02@mail.gmail.com> <6a7c66fc0711051057h343d0596m84413d827616478b@mail.gmail.com> Message-ID: <6a7c66fc0711051059h2975aa34g79062400764ccdfd@mail.gmail.com> > data Type = ForallT [Name] Cxt Type | VarT ConT Cons | AppT Type Type obviously I meant data Type = ForallT [Name] Cxt Type | VarT Name | ConT Cons | AppT Type Type From taha at rice.edu Fri Nov 30 14:31:59 2007 From: taha at rice.edu (Walid Taha) Date: Fri Nov 30 14:27:46 2007 Subject: [Template-haskell] Doctoral and Post-doctoral openings at Rice In-Reply-To: <469238a40711301124y7edd221cubb1ff1006ea9250a@mail.gmail.com> References: <469238a40711301124y7edd221cubb1ff1006ea9250a@mail.gmail.com> Message-ID: <469238a40711301131g1d721dcamd4719e892ec2e4b3@mail.gmail.com> The Resource-Aware Programming (RAP) research group at Rice University is seeking qualified doctoral and post-doctoral students. The openings will support work on a wide range of topics, including the Concoqtion programming language, physically safe computing, and device drivers. The full descriptions of these positions can be found at: http://www.resource-aware.org/twiki/bin/view/RAP/OpeningsGraduate and http://www.resource-aware.org/twiki/bin/view/RAP/OpeningsPostdoctoral Funding for these positions is provided by the National Science Foundation (NSF) and by industrial partners including Intel, LogicBlox, and Schlumberger. Walid Taha, http://www.cs.rice.edu/~taha Department of Computer Science Rice University Houston, TX 77025