From alfonso.acosta at gmail.com Tue Feb 20 20:15:17 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Tue Feb 20 20:12:52 2007 Subject: [Template-haskell] Type variables within type quasiquotes Message-ID: <6a7c66fc0702201715j54cb5db6gfb8ede2bddd69195@mail.gmail.com> Hi, Contrary to what's stated in GHC's 6.6 user's guide (http://www.haskell.org/ghc/docs/6.6/html/users_guide/template-haskell.html ) type quasiquotes seem to work just fine when type variables are not used (i.e. things such as [t| Bool |]). But unfortunately GHC complains when I make use of type variables [t| Maybe a |] leads to "Not in scope: type variable `a' " Am I doing something wrong or did I run into one of the reasons why the guide says that type quasi-quotes are not implemented? Thanks in advance, Alfonso Acosta From simonpj at microsoft.com Wed Feb 21 03:13:53 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Wed Feb 21 03:07:43 2007 Subject: [Template-haskell] Type variables within type quasiquotes In-Reply-To: <6a7c66fc0702201715j54cb5db6gfb8ede2bddd69195@mail.gmail.com> References: <6a7c66fc0702201715j54cb5db6gfb8ede2bddd69195@mail.gmail.com> Message-ID: It's the latter I'm afraid. Type quasi-quotes just aren't fully implemented. You'll need to use the lower-level machinery. Like other bits of the not-implemented-yet stuff, this is quite do-able, but there hasn't been a strong enough demand (yet!). Simon | -----Original Message----- | From: template-haskell-bounces@haskell.org [mailto:template-haskell-bounces@haskell.org] On Behalf Of | Alfonso Acosta | Sent: 21 February 2007 01:15 | To: template-haskell@haskell.org | Subject: [Template-haskell] Type variables within type quasiquotes | | Hi, | | Contrary to what's stated in GHC's 6.6 user's guide | (http://www.haskell.org/ghc/docs/6.6/html/users_guide/template-haskell.html | ) type quasiquotes seem to work just fine when type variables are not | used (i.e. things such as [t| Bool |]). | | But unfortunately GHC complains when I make use of type variables | | [t| Maybe a |] leads to "Not in scope: type variable `a' " | | Am I doing something wrong or did I run into one of the reasons why | the guide says that type quasi-quotes are not implemented? | | Thanks in advance, | | Alfonso Acosta | _______________________________________________ | template-haskell mailing list | template-haskell@haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell From alfonso.acosta at gmail.com Wed Feb 21 12:37:33 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Feb 21 12:31:26 2007 Subject: [Template-haskell] Re: Saving the AST generated by Template Haskell In-Reply-To: <6a7c66fc0701251209o32ff549m35a2642e89482df1@mail.gmail.com> References: <6a7c66fc0701251209o32ff549m35a2642e89482df1@mail.gmail.com> Message-ID: <6a7c66fc0702210937j57fea8a0ie69bd0ba4fe4236b@mail.gmail.com> The example wasn't really clear, I anyway solved the issue. Here is a summary. The problem: There are some cases (at least when developing a DSEL with Templpate Haskell like I am) in which it might be really useful to keep the AST gathered by the TH quasi quotes for later processing during execution (not just at compile time as it is normally done). The solution: In order to do that it is necessary to splice the MetaAST (A TH AST expressed in TH AST syntax as well) of the AST which wants to be kept at compilation time. That MetaAST can be obtained by merely coding a Lift instance for Language.Haskell.TH.(Exp,Dec,Type), most of it is barely boilerplate code. In my opinion it would be a good idea to include an Lift instantiation of Language.Haskell.TH.(Exp,Dec,Type) in the TH library. On 1/25/07, Alfonso Acosta wrote: > Hi all, > > I'm using Template Haskell to design a small subset of a Hardware > Description DSEL (Domain Specific Embedded Language). > > My language supports higher order as the user can supply small > functions as arguments. I chose to parse them with TH because it > allows me to use plain Haskell for the function syntax (instead of > reinventing the wheel) but mostly because gives parsing for free. > > The AST of the functions must be kept by the embedded compiler so that > it can be later translated to a target language by one of the > potential backends of the embedded compiler. > > The problem is ... how to store that AST? > > Let me show an example > > ---- > import Language.Haskell.TH.Syntax > > -- sample function from the DSLE library > hdMapSY :: (HDPrimType a, HDPrimType b) => HDFun (a -> b) -> HDSignal > a -> HDSignal b > > > -- We keep the function's AST (to make program transformations in the backends) > newtype HDPrimFun = HDPrimFun [Dec] > deriving Show > > -- Type safety layer, we keep the function to make sure TH checks the > type (and possible further simulations) > data HDFun a = HDFun [Dec] a > deriving Show > > -- Helper constructor function, which suffers from the Saving-the-AST problem > -- mkMetaAST currently returns a phony value > mkHDFun :: Q [Dec] -> Q Exp > mkHDFun qd = do dx <- qd > metaASTnm <- newName "metaAST" > let funnm = getFunName dx > metaAST = mkMetaAST dx > metaASTdec = ValD (VarP metaASTnm) (NormalB metaAST) [] > return $ LetE (metaASTdec:dx) (AppE > (AppE > (ConE $ mkName "HDFun") > (AppE > (ConE $ mkName "HDPrimFun") > (VarE metaASTnm))) > (VarE funnm)) > > where getFunName :: [Dec] -> Name > getFunName [FunD nm _] = nm > getFunName _ = error "mkHDFun: toy example, just and exactly one dec!" > -- This function should create an AST expression from the AST > -- but it would be a big pain to code > mkMetaAST :: [Dec] -> Exp > mkMetaAST _ = AppE (ConE (mkName "LitE")) > (LitE (StringL "big pain to code!")) > > --- > > An example program coded in the DSLE could could be something like .. > > myCircuit :: HDSignal Int -> HDSignal Int > myCircuit = hdMapSY ($mkHDFun [d| f input = input+1 |]) > > > So the question is .. > > How can mkHDfun save the AST of "f input = input+1" (for which it > needs to create and return a metaAST) without the effort of having to > create boiler plate code for the whole TH library types? > > Did anyone do something similar before? > > I workaround would be saving the String of the AST with show, but Dec > nor Exp belong to the Read class, :S > > Thanks in advance, > > Alfonso Acosta > From igloo at earth.li Wed Feb 21 18:52:54 2007 From: igloo at earth.li (Ian Lynagh) Date: Wed Feb 21 18:46:41 2007 Subject: [Template-haskell] Re: [Haskell-cafe] Re: Saving the AST generated by Template Haskell In-Reply-To: <6a7c66fc0702210937j57fea8a0ie69bd0ba4fe4236b@mail.gmail.com> References: <6a7c66fc0701251209o32ff549m35a2642e89482df1@mail.gmail.com> <6a7c66fc0702210937j57fea8a0ie69bd0ba4fe4236b@mail.gmail.com> Message-ID: <20070221235254.GA21073@matrix.chaos.earth.li> On Wed, Feb 21, 2007 at 06:37:33PM +0100, Alfonso Acosta wrote: > > In my opinion it would be a good idea to include an Lift instantiation > of Language.Haskell.TH.(Exp,Dec,Type) in the TH library. I've just added th-lift to hackage (http://hackage.haskell.org/). You can use it to Derive lift for existing types. It doesn't cover all cases, but it should be easy enough to complete if someone is motivated to. I haven't tried to see if it is already enough to cover the TH datatypes themselves. Thanks Ian From alfonso.acosta at gmail.com Wed Feb 21 19:19:15 2007 From: alfonso.acosta at gmail.com (Alfonso Acosta) Date: Wed Feb 21 19:13:03 2007 Subject: [Template-haskell] Re: [Haskell-cafe] Re: Saving the AST generated by Template Haskell In-Reply-To: <20070221235254.GA21073@matrix.chaos.earth.li> References: <6a7c66fc0701251209o32ff549m35a2642e89482df1@mail.gmail.com> <6a7c66fc0702210937j57fea8a0ie69bd0ba4fe4236b@mail.gmail.com> <20070221235254.GA21073@matrix.chaos.earth.li> Message-ID: <6a7c66fc0702211619u14ccde34yed3aac4368016a8e@mail.gmail.com> Hi Ian, On 2/22/07, Ian Lynagh wrote: > I've just added th-lift to hackage (http://hackage.haskell.org/). You > can use it to Derive lift for existing types. If only I knew about it before coding it by hand. It anyway it wasn't that bad cause I only support a subset of the AST and my hand-made Lift instance serves as well to cut detect unused branches. I wonder if there is any work being done to port DriFT to TH. It would be great, cause it wouldn't require using an external tool anymore and the affected Haskell code wouldn't need to be preprocessed. From pasalic at cs.rice.edu Wed Feb 7 16:17:35 2007 From: pasalic at cs.rice.edu (Emir Pasalic) Date: Tue Mar 20 11:23:12 2007 Subject: [Template-haskell] GPCE'07: Calls for Tutorials/Workshops Message-ID: <0B985EDE-DDB3-49EA-9055-8E0120A8BCB0@cs.rice.edu> CALL FOR TUTORIAL PROPOSALS Sixth International Conference on Generative Programming and Component Engineering (GPCE'07) October 1-3, 2007 in Salzburg, Austria (co-located with ESWEEK'07). http://www.gpce.org/07 Important Dates * Submission deadline for tutorial proposals: Friday March 16th * Date for notification of acceptance: Monday April 9th Note that this call is for tutorial organizers; tutorial registration is with the conference registration. Overview Proposals for high-quality tutorials in all areas of generative programming and component-based development, from academic research to industrial applications, are solicited. Tutorial levels may be introductory, intermediate, or advanced. A tutorial's purpose is to give a deeper insight into an area than a conventional lecture. Tutorials extend over a half or a full day. This gives the speaker the possibility to select a proper length for their tutorial. The topic of a tutorial can come from a truly broad spectrum. Any interesting theme included but not restricted to the following topic list is welcome: * Generative programming * Reuse, meta-programming, partial evaluation, multi-stage and multi-level languages, step-wise refinement * Semantics, type systems, symbolic computation, linking and explicit substitution, in-lining and macros, templates, program transformation * Runtime code generation, compilation, active libraries, synthesis from specifications, development methods, generation of non-code artifacts, formal methods, reflection * Generative techniques for * Product lines and architectures * Embedded systems * Model-driven architecture * Component-based software engineering * Reuse, distributed platforms, distributed systems, evolution, analysis and design patterns, development methods, formal methods * Integration of generative and component-based approaches * Domain engineering and domain analysis * Domain-specific languages (DSLs) including visual and UML-based DSLs * Separation of concerns * Aspect-oriented programming and feature-oriented programming, * Intentional programming and multi-dimensional separation of concerns * Industrial applications However, you should keep in mind that a tutorial must be expected to attract a reasonable number of participants. This is most likely the case if the topic is new or relevant to a broad community. If you have deep experience in a GPCE topic area, from which others could benefit, please consider submitting a proposal. Submission Format, Recommendations, and Process For details on the submission format, recommendations for submissions, and an overview of the submission process, please see the complete GPCE'07 call for tutorial proposals at: http://www.gpce.org/07 Follow the "Tutorials" link in the left sidebar. Tutorial Chair Ulrik P. Schultz (University of Southern Denmark, Denmark) For additional information, clarification, or questions please feel free to contact the Tutorial Chair at tutorials07@gpce.org CALL FOR WORKSHOP PROPOSALS Sixth International Conference on Generative Programming and Component Engineering (GPCE'07) October 1-3, 2007 in Salzburg, Austria (co-located with ESWEEK'07). http://www.gpce.org/07 Important Dates * Submission deadline for workshop proposals: Friday March 16th * Date for notification of acceptance: Monday April 9th Note that this call is for workshop organizers; a later call will occur for workshop contributions. Overview GPCE workshops provide intensive collaborative environments where generative and component technology researchers and practitioners meet to discuss and solve challenging problems facing the field. We encourage proposals for innovative, well-focused workshops on a broad spectrum of component engineering and generative programming topics. All topics related to the theme of the conference are potential candidates for workshops. Workshops typically fall into the following categories: * A workshop may address a specific sub-area of generative and component technology in depth. * A workshop may cover areas that cross the borders of several sub areas. Workshops that cross the borders of the formal and the applied areas is one example. * A workshop may also cross the border to other technologies or software engineering fields, e.g. development processes. * A workshop may focus on the application and deployment of generative and/or component technology in areas such as telecommunications, mobile computing or real-time systems. Workshops reporting on industrial experiences are particularly welcome. Workshop topics are by no means limited to the categories mentioned above. However, in each case, the proposed area is supposed to have enough impetus to yield new results that can be considered important and worth more detailed investigation. Submission Format, Recommendations, and Process For details on the submission format, recommendations for submissions, and an overview of the submission process, please see the complete GPCE'07 call for workshop proposals at: http://www.gpce.org/07 Follow the "Workshops" link in the left sidebar. Workshop Chair Ulrik P. Schultz (University of Southern Denmark, Denmark) For additional information, clarification, or questions please feel free to contact the Workshop Chair at workshops07@gpce.org.