March 2006 - template-haskell

automatic instances for pretty printing and parsing
by Johannes Waldmann 09 Sep '06

09 Sep '06

Dear all, I use Text.PrettyPrint.HughesPJ and Text.ParserCombinators.Parsec heavily so I made some DrIFT rules for deriving the "obvious" instances for class ToDoc a where toDoc :: a -> Doc class Reader a where readerPrec :: Int -> Parser a http://141.57.11.163/cgi-bin/cvsweb/drift/src/UserRuleToDoc.hs?rev=1.5 Still I'd like to avoid external preprocessors (for hygienic reasons, and because they do not seem to fit well with the Cabal model) so I'd like to investigate whether I could get the same effect with Template Haskell (in ghc) - and what this would cost. Perhaps someone has solved a similar problem before. On the other hand, HaXml does need DrIFT it seems. -- -- Johannes Waldmann -- Tel/Fax (0341) 3076 6479/80 -- ---- http://www.imn.htwk-leipzig.de/~waldmann/ -------

3 2

RE: [Template-haskell] quasi quotes and Q monad
by Simon Peyton-Jones 14 Apr '06

14 Apr '06

I've read your message, but I can't figure out what problem you are trying to solve. Can you give a small example that demonstrates it? Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Ch. A. Herrmann | Sent: 02 January 2006 16:17 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] quasi quotes and Q monad | | Dear TH experts, | | I have a problem concerning the interaction of quasi quotes and the | quotation monad. Assume a code generating function f (... -> Q Exp) | which is parameterized by a code generating function g (of type | Exp -> Q Exp, or(?) Q Exp -> Q Exp). | | Expressing the problem in the simplest form, the actual instance for g | is (\x -> [| h($x) |]), where h is a toplevel Haskell function working | on arbitrary types, and function f instantiates x | with an expression which consists just of a single variable (VarE). In | order to splice x in the code ($x), the type of x must be (Q Exp). The | reason for that, as mentioned in the 2002 paper | by Sheard and Peyton Jones "Template Metaprogramming for Haskell", is | that the computation of x must be able to access the Q monad. The place | inside f where the actual name for the variable x is generated, has | already access to the Q monad and the *result* of g is | embedded in this monad, no problem. However, I cannot figure out how | this monad can be passed as an *argument* to g and conceptually, there | is no justification to pass this monad: it is just an offspring version | of the one where the lexical scope of g belongs to. | | The value I want to pass for x is of type Exp. Of course, I could turn | this type into (Q Exp) by applying return, but this artificial instance | of the Q monad would come from nowhere, not being connected with the | regular instance used, e.g., for the fresh name generation. | | Especially, I have the following questions: | * Is there a simple solution to this problem? If so, please tell me and | forget about the following questions. | * Is the quasi quote mechanism at all appropriate for what I want to do | or should one better change to the concrete AST representation? That | | would be unfortunate because my aim is to develop Template Haskell | examples which demonstrate ease of use. | * If return is used to turn an expression into monadic form before | splicing, is it possible that | (a) the consistency of fresh name generation is lost, even if one | does the name generation for the spliced expression oneself, | (b) something else goes wrong? | | Many thanks in advance and a Happy New Year | -- | Christoph Herrmann | | | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

3 3

Renaming in pretty printer
by Andy Gill 28 Mar '06

28 Mar '06

Template Haskell appears to be doing renaming during pretty printing. Take this example, that both prints the AST directly, as well as pretty printing. *Main> runQ ([| let x = 1 in x |]) >>= \x -> print (pprint x,x) ("let x_0 = 1\n in x_0",LetE [ValD (VarP x_7) (NormalB (LitE (IntegerL 1))) []] (VarE x_7)) The var x has name x_7 in the AST, but x_0 in the pretty printed version. Can someone comment on why this is done? Andy Gill

2 1

GPCE'06 Call for Tutorials/Workshops
by Emir Pasalic 07 Mar '06

07 Mar '06

------------------------------------------------------------------------ CALL FOR TUTORIALS/WORKSHOPS Fifth International Conference on Generative Programming and Component Engineering (GPCE'06) http://www.gpce.org/06/ October 22-26, 2006 Portland, Oregon (co-located with OOPSLA'06) Sponsored by ACM SIGPLAN, in cooperation with ACM SIGSOFT. Proceedings to be published by ACM Press. ------------------------------------------------------------------------ IMPORTANT DATES * Proposal submission deadline: Mar 18, 2006 * Date for notification of acceptance: May 01, 2006 WORKSHOPS --------- 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, e.g. model driven development. - 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 Workshop proposals should be sent in ASCII or PDF format to the workshop chairs and should consist of the following four parts: 1. Cover Page - Name of the proposed workshop. - Names and addresses of the organizers. - Primary contact. - Intended number of participants. - Requested Audio/Video equipment. 2. Abstract Why is the proposed workshop relevant to GPCE? The abstract should provide a short overview of the rationale for the workshop and the major topics. In particular, statements about the review process and ways to ensure creativity during the workshop would be appreciated. The abstract should preferably not exceed 200 words. 3. Call for Participation A preliminary version of the Call for Participation that the organizers must prepare if the workshop is accepted. It should provide a brief overview of the proposed workshop including a description of the goals of the workshops and the work practices. It may repeat some of the statements made on the abstract page, but should be targeted specifically to potential workshop participants. 4. Organizers Bio and Past Events - Short biography of each organizer. - References to similar workshops organized at previous conferences, including the number of participants. If a workshop is accepted, the organizers will be requested to prepare a WWW page that will contain the latest information about the workshop. The web pages of each workshop will be linked to the GPCE workshop web site. Each workshop must have at least two organizers, preferably from different organizations. Please keep complete submissions to under four pages. Submission Process Electronic submission of proposals must be sent to workshops06(a)gpce.org. Proposals must be submitted no later than Mar 18, 2006, BUT EARLIER IS BETTER, as it allows for a more satisfactory coordination between workshop proposals. For More Information The complete call and additional information can be found at http://www.gpce.org/06/. For additional information, clarification, or questions please feel free to contact the Workshop Chairs (workshops06(a)gpce.org) The workshop chairs Christa Schwanninger, Siemens AG Hans-Arno Jacobson, University of Toronto TUTORIALS --------- 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 nteresting 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 development / 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 Proposals must contain all information specified in the tutorial submission template. See http://www.program-transformation.org/GPCE06/SubmissionFormat What should a tutorial look like? In case your tutorial is accepted, the tutorial guidelines document offers suggestions for preparing and presenting your tutorial. See http://www.program-transformation.org/GPCE06/TutorialGuideline Submission Process Electronic submission of proposals must be sent to tutorials06(a)gpce.org. Proposals must be submitted no later than Mar 18, 2006. The proposals received will be reviewed by the Tutorial Committee to ensure a high quality and appropriate mix for the conference. The Tutorial Chairs will work toward a diverse program that attracts a large interest among the broad segments within GPCE. For More Information The complete call and additional information can be found at http://www.gpce.org/06/. For additional information, clarification, or questions please feel free to contact the Tutorial Chairs (tutorials06(a)gpce.org) The tutorial chairs Christa Schwanninger, Siemens AG Hans-Arno Jacobson, University of Toronto

1 0