- template-haskell - Haskell.org

Re: [Template-haskell] [Haskell-beginners] DOOM rewritten in the Haskell programming language.
by Sumit Sahrawat, Maths & Computing, IIT (BHU) 07 Dec '15

07 Dec '15

I'm interested in game development, and would be willing to learn and contribute if the project kicks off. Just showing my support, good luck with the project. On 7 December 2015 at 16:24, Alexander Berntsen <alexander(a)plaimi.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > David, > > I think it would be more valuable to make a DOOM-like game than to > remake DOOM. Especially if you are going to aim for funding. The free > software community has had this problem for years, where we point to > remakes of old games as evidence to viability. It isn't. Nobody will > be swayed by Haskell DOOM. (Although I would, personally, think it > interesting.) > > Good luck with your project. > - -- > Alexander > alexander(a)plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCgAGBQJWZWV0AAoJENQqWdRUGk8B0bMQAKu/4hBeS7Iz23IMIatrc5Jd > hkWm/bG8FRCtiLyETiH9NtUL5RPtmS+s3+o05h6fZZ1VFFfzucygsmOTw27kWApc > ZpZiypv22y7uJsrbyxFgXVp2w6vfp6rrdA+vRSOUp/dmJ+vnn7jVeGUInnlAKX50 > WAsEUPx0q4IhGnF/2O3kBuKw/baGvp2kne2IjrgdAJ5qptVEvVoAEpIG3WveTnlP > LQMBwTLrB+TkdTIZWTYUT/e8MYZorU5x6LN+GtKuO28PEEG0jS2IgfNeUnzZjalF > p37Av84UCiIhTQD3LV6Eq1sQThQMVMm/S+qkqZrNL3I/+TbS3Ztf6q7u7zDRCsnr > vum2JR0f9vtGfpd5j3hGVXjQTd0jU3uFdY1kHM0ISGTSKYrOGYs4qsCL/VxPubo8 > Lh7YfCltXY+LQkz/Q2FElcd9eM9xYWSOBhPhiudXZ3f+PnkBNRwH03eWk/LHgmhB > MByAdf2WCAU4DK7xpJKkCVsyOlsC17t8CtKDIfnt/RkPUr8108i6KOh6zvDR94Du > lJyQWuCbL7FFb7uXVO7cKTeWJFejd/K5GrQBTBpVEy3xA15c8Kj+9ALWrdJAlion > ktS85eEcp/3IzrNpPby8lhjJvujwzbzny+a9Jdn8ZcybBwpF3+IRSARnb7lJ4Yba > Ca972BfXJnFZXiYARfov > =mGnp > -----END PGP SIGNATURE----- > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners > -- Regards Sumit Sahrawat

1 0

Lista de emails como fazer uma mala direta email de empresas
by Ed Soares 24 Nov '13

24 Nov '13

Lista de emails como fazer uma mala direta email de empresas emails de empresas que inclui lista de emails, mala direta como fazer endereco de email: http://www.maladiretaemails.com muito mais do que mailing, é realmente otimo para praticamente todos. email em massa trabalhe com mala direta também lista de emails, listas de emails mail marketing, o objetivo de nosso website. no caso de você querer lista de emails gratis, mala direta como fazer e, além disso trabalho com mala direta: http://www.maladiretaemails.com pode ser bastante bom email lista além de endereco de email, email em massa listas email. é ótimo lista de email além de mala direta o que é. email lista gratis como fazer mala direta, cadastro email. atualmente listagem de empresas que contém Enviar email, listas email é bom. é realmente o propósito de nosso website: mala direta como fazer, Enviar email, bem como Enviar email gratis. Temos o que há de melhor em listagem de empresas Enviar email gratis, email lista gratis.

1 0

Lista aprovados Branquinha
by Edson 29 May '13

29 May '13

Lista aprovados Branquinha: Querência: AMANDA AZEVEDO DE CASTRO FROTA ARAGAO, LEONARDO ARAUJO DE SOUSA, FRANCISCA NAGIELE SILVA, PABLO RICHEL SOARES MENDES, JOÃO CARLOS MOREIRA DE CARVALHO, CLOVIS JOSE PINHEIRO PADILHA, MARIA DE LOURDES CORDEIRO, IZAEL DIAS DA SILVA. SANDRO NEVES DE SILVA, EMYLIA KAROLINE ARARUNA MACEDO, MAYALLE DE LIMA, JOSELÂNE DOS SANTOS FERREIRA, WANDERLEIYA CICERA SIQUEIRA. Junco do Maranhão. Branquinha, ANNE KAROLYNE PEREIRA DA SILVA, LUCAS FERREIRA DANTAS, GERLAN LOPES DA COSTA, RAFAELA SOARES DOS ANJOS, JOÃO CARLOS MOREIRA DE CARVALHO, DENIS BARROS SILVA, MARIA MICAELE ALVES DE MELO, JOEL FERREIRA MADUREIRA. TAYANE ASSUNÇÃO NEVES, CAMILLA KEILHANY DE SOUSA CAETANO, MAIARA MUSY ARAUJO, IALE NAIANE MARIANO DOS PASSOS, ROAN CADMUS RODRIGUES DAMASCENO. Cachoeira Dourada. Nova Ibiá e ANA CLEIDE PEREIRA DE VASCONCELOS, LUAN MARINHO DE SOUZA, FRANCISCO LEANDRO FIUSA DA SILVA, PEDRO HENRIQUE ARAUJO SANTIAGO, JOÃO CARLOS MOREIRA DE CARVALHO, DANIEL DA CUNHA MAGALHAES, MARIA IVANI DE ARAÚJO, JEANNIE PAULO DE SOUSA. SILVANA GALDINO FERREIRA, AUGUSTO BRUNO PEREIRA DOS SANTOS, LUCIANA ESTELITA LAFAYETTE RABELO, GRACY KELLY DE LIMA MORAIS, REJANE CRISTINA SANTOS DE OLIVEIRA. Itapuranga.

1 0

Call for Papers - ASE 2013
by ASE2013 28 Feb '13

28 Feb '13

CALL FOR PAPERS 28th IEEE/ACM International Conference on Automated Software Engineering ASE 2013 http://ase2013.org November 11th - 15th 2013, Silicon Valley, California * Conference * Tool Demos * Workshops * Tutorials * Doctoral Symposium * IMPORTANT DATES Abstract Submission: May 10, 2013 Paper Submission: May 17, 2013 Notification: July 24, 2013 Tool Demonstration Paper Submission: June 6, 2013 Workshop Proposal Submission: April 26, 2013 Workshop Paper Submission: August 9, 2013 Tutorial Proposal Submission: July 5, 2013 Doctoral Symposium Submission: July 10, 2013 GENERAL THEME The IEEE/ACM Automated Software Engineering (ASE) Conference series is the premier research forum for automating software engineering. Each year, it brings together researchers and practitioners from academia and industry to discuss foundations, techniques and tools for automating the analysis, design, implementation, testing, and maintenance of large software systems. === MAIN CONFERENCE PAPERS ============================================= [http://ase2013.org/calls.html] ASE 2013 invites high quality contributions describing significant, original, and unpublished results for submission in three categories: 1. Technical Research Papers should describe innovative research in automating software development activities or automated support to users engaged in such activities. They should describe a novel contribution to the field and should carefully support claims of novelty with citations to the relevant literature. Where a submission builds upon previous work of the author(s), the novelty of the new contribution must be clearly described with respect to the previous work. Papers should also clearly discuss how the results were validated. 2. Experience Papers should describe a significant experience in applying automated software engineering technology and should carefully identify and discuss important lessons learned so that other researchers and/or practitioners can benefit from the experience. Of special interest are experience papers that report on industrial applications of automated software engineering. 3. New Ideas Papers (new category!) should describe novel research directions in automating software development activities or automated support to users engaged in such activities. New ideas submissions are intended to describe well- defined research ideas that are at an early stage of investigation and may not be fully validated. SUBMISSION All submissions must come in PDF format and conform, at time of submission, to the IEEE Formatting Guidelines. For details and templates, see: http://www.conference-publishing.com/Instructions.php?Event=ASE13 Technical Research Papers and Experience Papers must not exceed 10 pages (including figures and appendices) plus up to 1 page that contains ONLY references. New Idea Papers must not exceed 6 pages (including figures, appendices AND references). Submissions that do not adhere to these limits or that violate the formatting guidelines will be desk-rejected without review. All submissions must be in English. The submission site will be posted on the conference website (http://ase2013.org) Papers submitted to ASE 2013 must not have been previously published and must not be under review for publication elsewhere. All papers that conform to submission guidelines will be peer-reviewed by members of the Program Committee and members of the Expert Review Panel. Submissions will be evaluated on the basis of originality, soundness, importance of contribution, evaluation, quality of presentation and appropriate comparison to related work. Note that the Program Committee may re-assign a submission into a different category than the one it is submitted to if it decides that it is a better fit for that category. All accepted papers have to be presented at the conference by one of the authors and will be published by IEEE. === TOOL DEMONSTRATIONS ================================================ [http://ase2013.org/tools.html] Automated software engineering consists of automating processes related to requirements, design, implementation, testing, and maintenance of software systems. The automated processes facilitate better productivity and improve the overall quality of software. Tool development is an integral part of automated software engineering. The tool demonstrations track provides an opportunity for researchers and practitioners to present and discuss the most recent advances, experiences, and challenges in the field of automated software engineering. The ASE conference solicits high-quality submissions for its tool demonstrations track. We invite submission on tools that are (a) early research prototypes or (b) mature tools that have not yet been commercialized. The submissions should highlight the underlying scientific contributions, engineering ingenuity, applicability to a broader software engineering community, and scalability of the tool. In contrast to a research paper which is intended to provide details of a novel automated software engineering technique, a tool demonstration paper should provide an overview of how the technique has been implemented as a functioning tool. Authors of regular research papers are thus encouraged to submit an accompanying tool demonstration paper. EVALUATION The tool demonstration program committee will review each submission to assess the relevance and quality of the proposed tool demonstration in terms of usefulness of the tool, presentation quality, and appropriate discussion of related tools. Accepted tool demonstrations will be allocated 4 pages in the conference proceedings. Demonstrators will be invited to give a presentation of the tool during the conference. There will also be an area open to attendees at scheduled times during the conference during which demonstrators can present live demonstrations. Presentation at the conference is a requirement for publication. Prizes will be given for an overall best tool demonstration and a best student tool demonstration where a student is the first author on the paper and presents the demonstration. The prizes will be decided based on the votes of the conference attendees. SUBMISSION Submissions should: * Consist of a proposal of at most 4 pages that adheres to the ASE 2013 proceedings format (IEEE proceedings style). The proposal should provide an overview of the tool, how it relates to other industrial or research tools, including references, and its potential impact to a broader software engineering community. * Provide a link to a video, not more than 5 minutes long, that demonstrates the tool being used. The goal of the video is to provide the reviewers a usage overview of the tool that enables them to evaluate the tool. A screencast of the tool demo with a voice-over can be used for the video. * Provide a URL from which the tool can be downloaded, with clear installation steps. If the tool cannot be made available, the authors must clearly state their reasons in the paper. Examples and scenarios presented in the paper should be independently replicable. * Be submitted by June 6, 2013 via EasyChair: https://www.easychair.org/conferences/?conf=ase2013tools Contact: asetools2013(a)easychair.org === WORKSHOPS ========================================================= [http://ase2013.org/workshops.html] A workshop co-located with the ASE 2013 conference should provide an opportunity for exchanging views, advancing ideas, and discussing preliminary results on topics related to Automated Software Engineering. Workshops may also serve as platforms to nurture new scientific communities. Workshops should not be seen as an alternative forum for presenting full research papers. The workshops co-located with the conference will be organized before the main conference (Monday, Tuesday). The organizers will decide the exact day after the proposals have been reviewed and accepted. A workshop may last one or two days. SUBMISSION Proposals for organizing workshops should be written in English, limited to 5 pages (in IEEE format), and submitted in PDF to both workshop co-chairs, by email at ase2013workshops(a)easychair.org. Workshop proposals should include the following information: * Theme and goals of the workshop including its relevance to the field of Automated Software Engineering * Targeted audience and the expected number of participants (minimum and maximum) * Workshop format (e.g., paper presentations, breakout sessions, panel-like discussions, combination of formats) * The equipment, room capacity, and any other resource necessary for the organization of the workshop * Participant solicitation and selection process * Workshop publicity strategy that the workshop organizers will use * Brief description of the organizer's background, including relevant past experience on organizing workshops and contact information * Initial version of the call for papers that the workshop organizers intend to use * Preferences for workshop dates, duration (1 or 2 days), and any other scheduling constraints Note that the workshop co-chairs will consider the preference of workshop dates specified by the organizers, but the acceptance of a workshop proposal does not guarantee adherence to the requested date/time. The workshop co- chairs will assume that workshop proposers will be able to run a workshop on the dates that ASE 2013 has reserved for workshops. Review Process. Workshop proposals will be reviewed by the ASE 2013 tutorials and workshop co-chairs. Acceptance will be based on an evaluation of the workshop's potential for generating useful results, the timeliness and expected interest in the topic, the organizer's ability to lead a successful workshop, and the potential for attracting a sufficient number of participants. Accepted workshops must adhere to the common deadlines listed below for submissions of papers, acceptance of papers, and preparation of proceedings. Contact. ase2013workshops(a)easychair.org === TUTORIALS ========================================================== [http://ase2013.org/tutorials.html] Tutorials may address a wide range of mature topics from theoretical foundations to practical techniques and tools for automated software engineering. The tutorials will be organized before the main conference (Monday, Tuesday). The organizers will decide the exact day after the proposals have been reviewed and accepted. Tutorials are intended to provide independent instruction on a relevant theme; therefore, no commercial or sales-oriented proposals will be accepted. SUBMISSION Instructors are invited to submit proposals for half-day or full-day tutorials and, upon selection, are required to provide tutorial notes or a survey paper on the topic of presentation in PDF. Proposals for organizing tutorials should be written in English, limited to 5 pages (in IEEE format), and submitted in PDF to both tutorials co-chairs, by email at: ase2013tutorials(a)easychair.org. Tutorial proposals should include the following information: * Name and affiliation of the proposer/organizer (including postal address, phone number, fax number, e-mail address) * Name and affiliation of each additional instructor * Instructors' experience in the area, including other tutorials, courses, etc. * Title, objective, abstract, duration * Outline with approximate timings * Target audience, including indication of level (novice, intermediate, expert) * Assumed background of attendees * Brief biography of each instructor (for publicity materials) * Indication of whether a survey paper will be provided (max. 30 IEEE-formatted pages) * History of the tutorial (if it has been already presented; provide location, estimated attendance, etc.) * Justification for full day (if a full day is proposed) * Audio-visual and technical requirements * References including the proposers' papers on the subject * Preferences for tutorial date, duration (half-day or full-day), and any other scheduling constraints Preferences for tutorial date, duration (half-day or full-day), and any other scheduling constraints Note that the tutorial co-chairs will consider the preference of tutorial dates specified by the organizers, but the acceptance of a tutorial proposal does not guarantee adherence to the requested date/time. The tutorial co-chairs will assume that tutorial proposers will be able to run a tutorial on the dates that ASE 2013 has reserved for tutorials. Review Process. Tutorial proposals will be reviewed by the ASE 2013 tutorials and workshop co-chairs. Acceptance will be based on the timeliness and expected interest in the topic, the proposer's ability to present an interesting tutorial, and the potential for attracting a sufficient number of participants. Contact. ase2013tutorials(a)easychair.org === DOCTORAL SYMPOSIUM ================================================= [http://ase2013.org/ds.html] The goal of the ASE 2013 Doctoral Symposium is to provide a supportive yet questioning setting in which the PhD students have an opportunity to present and discuss their research with other researchers in the ASE community. The Symposium aims to provide students with useful guidance and feedback on their research and to facilitate their networking within the scientific community by interacting with established researchers and with their peers at a similar stage in their careers. The technical scope of the Symposium is that of ASE. Students should consider participating in the Doctoral Symposium after they have settled on a dissertation topic with some initial research results. Students should be at least a year from completion of their dissertation (at the time of the Symposium), to obtain maximum benefit from participation. The Doctoral Symposium is open to Ph.D. students at any stage of their research, whereby students at the initial stage (first or second year) will be able to challenge their ideas and current research directions, while students at a more mature stage (third or fourth year) will be able to present their thesis and get advice for improvement and for better exposition of their contributions and conclusions. Attendance is open to students of accepted research abstracts and Doctoral Symposium committee members. EVALUATION The Doctoral Symposium Committee will select participants using the following criteria: * The potential quality of the research and its relevance to ASE * Quality of the research abstract. * Diversity of background, research topics and approaches. Students should not infer that a list of prior publications is in any way expected or required; we welcome submissions from students for whom this will be their first formal submission as well as those who have previously published SUBMISSION To apply as a student participant in the Doctoral Symposium, you should prepare a submission package consisting of two parts, both of which must be submitted by the submission deadline. Part 1: Research Abstract (max. 4 pages). Your research abstract must conform to the ASE 2013 formatting and submission instructions and should cover: * Your targeted research problem with justification of its importance * Discussion why related and prior work has not solved the problem * A sketch of the proposed approach or solution * The expected contributions of your dissertation research * Progress you have made so far in solving the stated problem * The methods you are using or will use to carry out your research * A plan for evaluating your work and presenting credible evidence of your results to the research community * A list of any publications either appeared, accepted or submitted for which the student is an author. Students at the initial stage of their research might have some difficulty in addressing some of these areas, but should make their best attempt. The research abstract should include the title of your work, your name, your advisor, your email address, postal address, personal website, and a one paragraph short summary in the style of an abstract for a regular paper. Please submit your research abstract using the EasyChair submission site: https://www.easychair.org/conferences/?conf=dsase13 Part 2: Letter of Recommendation. Please ask your dissertation advisor for a letter of recommendation. This letter should include your name and a candid assessment of the current status of your dissertation research and an expected date for dissertation submission. The letter should be in Adobe Portable Document Format (PDF), and sent to: Marsha Chechik and Paul Gruenbacher at ase-org(a)cs.toronto.edu with the subject: ASE 2013 DOCTORAL SYMPOSIUM RECOMMENDATION. Acceptance. All accepted papers will be published by IEEE. Authors of accepted contributions will receive further instructions for preparing their camera ready versions. Authors must register for the ASE 2013 Doctoral Symposium and present their work at the Symposium. === ORGANIZATION ======================================================= General Chair Ewen Denney, SGT / NASA Ames Program Chairs Tevfik Bultan, University of California, Santa Barbara Andrease Zeller, Saarland University, Saarbruecken Program Committee Andrew Begel, Microsoft Research Myra Cohen, University of Nebraska - Lincoln Danny Dig, University of Illinois at Urbana-Champaign Bernd Fischer, Stellenbosch University / University of Southampton Gordon Fraser, University of Sheffield Harald Gall, University of Zurich Dimitra Giannakopoulou, NASA Ames Research Center Alex Groce, Oregon State University Paul Gruenbacher, Johannes Kepler University Linz Arie Gurfinkel, Carnegie Mellon University US William G.J. Halfond, University of Southern California Mark Harman, University College London Sunghun Kim, The Hong Kong University of Science and Technology David Lo, Singapore Management University Shahar Maoz, Tel Aviv University Darko Marinov, University of Illinois at Urbana Champaign Tim Menzies, West Virginia University Mira Mezini, Technische Universitaet Darmstadt Tien Nguyen, Iowa State University Corina Pasareanu, CMU, NASA Ames Lori Pollock, University of Delaware Martin Robillard, McGill University Grigore Rosu, University of Illinois at Urbana Champaign Abhik Roychoudhury, National University of Singapore Gabriele Taentzer, Philipps Universitaet Marburg Nikolai Tillmann, Microsoft Research Sebastian Uchitel, Universidad de Buenos Aires/Imperial College London Willem Visser, Stellenbosch University Lu Zhang, Peking University Charles Zhang, Hongkong University of Science and Technology Doctoral Symposium Co-Chairs Marsha Chechik, University of Toronto Paul Gruenbacher, Johannes Kepler University Linz Doctoral Symposium Committee Jamie H. Andrews, University of Western Ontario Myra B. Cohen, University of Nebraska - Lincoln Elisabetta Di Nitto, Politecnico di Milano Darko Marinov, University of Illinois at Urbana-Champaign Charles Pecheur, Universite Catholique de Louvain Andrea Zisman, City University London Workshop and Tutorial Co-Chairs Marcelo d'Amorim, Federal University of Pernambuco David Lo, Singapore Management University Tool Demonstration Chairs Andrew Ireland, Heriot-Watt University Neha Rungta, SGT / NASA Ames Finance & Local Arrangements Ganesh Pai, SGT / NASA Ames Publicity Chair Christoph Gladisch, Karlsruhe Institute of Technology Social Media Chair Tien Nguyen, Iowa State University

1 0

change in [d| |] and creating instances in template-haskell 2.7
by Jeremy Shaw 07 Sep '11

07 Sep '11

Hello, I have some code that likes like this, which works in template-haskell 2.5 / GHC 7.0.3: --------------- {-# Language TemplateHaskell, TypeFamilies #-} module Show where import Language.Haskell.TH class Bar a where bar :: a -> String inferBar :: Name -> Q [Dec] inferBar typeName = do s <- [d| bar _ = "sucker" |] d <- instanceD (return []) (appT (conT ''Bar) (conT typeName)) (map return s) return [d] ----------------- $(inferBar ''Bool) But, in template-haskell 2.6 / GHC 7.2.1, I get an error, Warning: No explicit method nor default method for `bar' In the instance declaration for `Bar Bool' Comparing the output of -ddump-splices we see in GHC 7.0.3/ TH 2.5, we have: bar-test.hs:1:1: Splicing declarations inferBar 'Bool ======> bar-test.hs:4:3-17 instance Bar Bool where { bar _ = "sucker" } But in GHC 7.2.1 / TH 2.6 we have: bar-test.hs:1:1: Splicing declarations inferBar 'Bool ======> bar-test.hs:4:3-17 instance Bar Bool where { bar_acAU _ = "sucker" } The difference being that instead 'bar' we have 'bar_acAU'. So maybe that is why it can't find the method 'bar' in the instance declaration? Though, I would kind of expect an error like, `bar_acAU' is not a (visible) method of class `Bar'. Am I doing something wrong? Should I file a bug ? Thanks! - jeremy

1 0

Is it evil to add "deriving Typeable" to newtype Q?
by Leonel Fonseca 05 May '10

05 May '10

Hi everybody, Is it reasonable to add "deriving Typeable" to newtype Q? In case you wonder why I want to do that, it is because I've constructed a Q [Dec] inside a monad, I want to extract it from the monad (via runIO) and the monad has constraint "Typeable" over this parameter. I've also tried to write the Typeable instance in my own module (not Language.Haskell.TH.Syntax). But I've got no luck since the Q type constructor is exported but the data constructor is not. Thanks. -- Leonel Fonseca.

2 1

Querying the instances a data type implements
by jonathanGfischoff＠gmail.com 19 Jan '10

19 Jan '10

Hi, I am trying query the instances that a data type implements. Calling reify on the data type doesn't appear to return anything relating to type classes. I am very new to Template Haskell, so I apologize if there is a easy way to do this that I missed. -Jonathan

4 3

Generating function implementations from a list of patterns
by Lars Kotthoff 29 Nov '09

29 Nov '09

Hi list, I'm trying to generate function implementations given a list of patters to match the function argument. For example, given data Foo = Foo Int | Bar Int foobar (Foo i) = i foobar (Bar i) = i The body of the "foobar" function is the same for all the patterns, therefore I'd like to generate it. In particular, I'd like to be able to write something like (pseudo-template-haskell) $(genFunc ''foobar [(''Foo i), (''Bar i)] i) i.e. have a function genFunc which takes the name of the function to define, the list of patterns and the function body as arguments. I've played around with the example for deriving Show on the wiki, but I didn't really get anywhere. Any pointers how to do this? Thanks, Lars

1 0

How to extract name and type of exported functions in modules
by Oscar Finnsson 29 Oct '09

29 Oct '09

Hi, I'm trying to extract the names and types of exported functions in a module. At the moment I've managed to get a list of all functions in a module but I can't seem to figure out how to get their types. Lets say I got the module module Foo where foo1 :: String -> String foo1 value = value foo2 = "hej" and then in anothor module... module Bar where bar = $(getAllFunctions "<some-path>/Foo.hs") At the moment I got getAllFunctions returning ["foo1","foo2"], but I would really like to get it to return [("foo1",AppT (ConT "String") (ConT "String")), ("foo2",ConT "String")] Using "parseModuleWithMode" from Language.Haskell.Exts I can get hold of the names and the type signature of foo1 (since it's specified in the source code) but I cannot get hold of the type signature of foo2 (since it's not specified in the source code). Is there another way to get the names/signatures of exported functions from a module other than using parseModuleWithMode so the developer writing the Foo-module isn't forced to explicitly supply type signatures of the exported functions? If I try "reify" to get information about the functions I get the error message: "foo1 is not in scope at a reify" This seems to be a known bug about reify (reported here http://hackage.haskell.org/trac/ghc/ticket/2339) My problem is that I cannot use the workaround since I don't know the name of the functions. Another disadvantage with this approach is that "getAllFunctions" must have access to the source code of the module and that I must supply the path the the module. If possible I would like to have code such as bar = $(getAllFunctions "Foo") instead of "<come-path>/Foo.hs". Regards, Oscar Finnsson

3 4

Generating arithmetic expressions in TH
by Vitor Rodrigues 22 Oct '09

22 Oct '09

Hello, I am starting using TH to generate lambda expressions representing arithmetic expressions. My current problem is to generate code where all the lambda abstractions are in the top level. For example, I would like to have \x -> 1 + x instead of 1 + (\x -> x) My problem is that I don't know in beforehand if the second operand is a variable or not. If so, I would like to build a top level abstraction. It is this possible? Regards, Vitor

2 1