February 2005 - template-haskell

RE: template-haskell
by Simon Peyton-Jones 28 Feb '05

28 Feb '05

Yes, quoted code is typechecked. The right way to express the result would be for the TH implementation to make a data structure (Exp, Decl etc) representing the *typed* code, and then do_something could look at those types. This does come up quite regularly. So why have I not done it? (a) It needs some design work on TH syntax. It must be able to express typed code (produced by quotes) and untyped code (produced by the user's program) (b) The types are only partly there. For example \x -> $(do_something [| \y -> x |]) Here the (\y->x) doesn't know the full type for x. Indeed just, x's type may not be fully worked out by the time do_something runs. For example we might have \x -> ($(do_something [| \y -> x |]), x::Int) Eventually we know that x::Int, but perhaps not when we run do_something. It depends on the order in which the type checker does things. This is a pretty nasty problem because the semantics of TH would then depend on order of type checking etc. (c) When type checking a splice, should we ignore types in the TH code, or respect them? And, of course, it's work do to. The big one is (b). A pragmatist would say just go ahead and hack something up -- if you get type information it'll be accurate, but there's no guarantee of what you'll get. But I hate that. So that's why I keep postponing it. Better ideas welcomed. Simon | -----Original Message----- | From: Keean Schupke [mailto:k.schupke@imperial.ac.uk] | Sent: 23 February 2005 14:16 | To: Simon Peyton-Jones | Subject: template-haskell | | Had a bit of a chat on the template-haskell list about type checking | meta quoted code... would it be possible (as I don't think it is currently | supported) to get the type of meta-quotes expressions,. like: | | $(do_something [| | f a = a + 1 |] ) | | such that inside the splice we can access the type info for 'f'. | | I know it is type checked, because if will pick up type errors in the | meta quotes, | before macro expansion. | | One way of doing this would be to annotate the meta-quote with the type | info like: | | [| | f :: Num a => a -> a | f a = a + 1 | |] | | In other words if the type sig for 'f' is not given, add it to the data | structure returned from | the meta quotes... | | What do you think? possible? easy/hard? | | Keean.

2 1

Re: Proposal: Allow "\=" for field update in record update syntax
by S. Alexander Jacobson 28 Feb '05

28 Feb '05

Since this didn't get a response on the Haskell list, I thought I would forward it here.... On Sat, 19 Feb 2005, Andre Pang wrote: > On 19/02/2005, at 5:20 AM, Keean Schupke wrote: > >> Yes, your idea is much nicer... I was just suggesting TH as a way to >> implement custom syntax... It would be nice if come sort of standard >> existed for template-haskell so that other compilers/interpreters could >> adopt it. A portable template would be a cool thing. > > The $(...) syntax that you need at the splice site greatly diminishes the > potential for Template Haskell to be used as syntax, unfortunately. The > interesting (or frustrating?) thing is that Template Haskell implements the > majority of the hard work needed for a proper hygienic macro system, but > unfortunately doesn't go quite the extra mile to enable you to actually > define new syntax. I suspect all you'd need is a way to annotate the > function you wanted to use as a macro, so that the compiler knows that the > function should always be spliced in, rather than be explicitly spliced in at > the call site. (People who know better, shoot me down if I'm wrong ...) > > I'd actually go so far blame the lack of macro support in TH on the Haskell > community as a whole, since the general consensus I get from e.g. the mailing > lists is that "syntactic sugar is bad". > > > -- > % Andre Pang : trust.in.love.to.save <http://www.algorithm.com.au/> > ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

1 0

Re: [Haskell] Proposal: Allow "\=" for field update in record update syntax
by S. Alexander Jacobson 28 Feb '05

28 Feb '05

Since operators can't start with a ':', is there an in-principle reason TH does not support : operators? The syntax below would be really nice to have. On Fri, 18 Feb 2005, Sander Evers wrote: > >> Then we could have e.g. (:=) and (:\=) and end up with a >> syntax that looks like this: >> >> rec // field :\= fn . field2 := val >> >> And that is BETTER than the Haskell syntax that I originally proposed. > > This syntax is also nice for composition of update functions, which is useful > with nested records: > > data Country = Country {capital :: City, ...} > data City = City {inhabitants :: Int, ...} > > birth_in_capital :: Country -> Country > birth_in_capital = capital :\= (inhabitants :\= (+1)) > > This also shows that it would be useful to make :\= associate to the right. > ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

1 0

CFP: GPCE'05 -- Generative Programming and Component Engineering
by Eelco Visser 22 Feb '05

22 Feb '05

FIRST CALL FOR PAPERS ---------------------------------------------------------------------- 4th International Conference on Generative Programming and Component Engineering (GPCE'05) Sep 29 - Oct 1, 2005, Tallinn (Estonia) http://www.gpce.org/05 Sponsored by ACM SIGPLAN, in cooperation with ACM SIGSOFT co-located with ICFP'05 and TFP'05 ---------------------------------------------------------------------- Consult http://www.gpce.org/05 for UP-TO-DATE and DETAILED information, including the full text of the calls for PAPERS and DEMONSTRATIONS, and the calls for workshop and tutorial proposals. APPROACHING: Deadline for WORKSHOP and TUTORIAL PROPOSALS FORTHCOMING: web page for submission of papers and demos (early March) ---------------------------------------------------------------------- IMPORTANT DATES * Feb 25, 2005: Submission of workshop and tutorial proposals * Mar 18, 2005: Notification for workshop and tutorial proposals * Apr 10, 2005: Submission of abstracts (only for papers) * Apr 15, 2005: Submission of papers and demos * May 30, 2005: Notification for papers and demos * Sep 27-28, 2005: GPCE workshops and tutorials * Sep 29 - Oct 1, 2005: GPCE papers and demos ---------------------------------------------------------------------- SCOPE. Generative and component approaches have the potential to revolutionize software development in a similar way as automation and components revolutionized manufacturing. Generative Programming (developing programs that synthesize other programs), Component Engineering (raising the level of modularization and analysis in application design), and Domain-Specific Languages (elevating program specifications to compact domain-specific notations that are easier to write and maintain) are key technologies for automating program development. GPCE arose as a joint conference, merging the conference on Generative and Component-Based Software Engineering (GCSE) and the workshop on Semantics, Applications, and Implementation of Program Generation (SAIG). The goal of GPCE is to provide a meeting place for researchers and practitioners interested in cutting edge approaches to software development. We aim to foster further cross-fertilization between the software engineering research community and the programming languages community, in addition to supporting the original research goals of both the GCSE and the SAIG communities. ---------------------------------------------------------------------- TOPICS. GPCE seeks contributions both in software engineering and in programming languages related (but not limited) to: * 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 and feature-oriented programming, - Intentional programming and multi-dimensional separation of concerns * Industrial applications ---------------------------------------------------------------------- CALL FOR PAPERS. Authors are invited to submit a title and abstract (by Apr 10) and a full paper (by Apr 15) reporting research results and/or experience related to the topics above. We especially encourage original high-quality reports on applications to real-world problems, relating ideas and concepts from several topics, or bridging the gap between theory and practice. Simultaneous submission to other venues and submission of previously published material are not allowed. Accepted papers will appear in the conference proceedings, to be published in Springer's LNCS series. SUBMISSION GUIDELINES. Electronic submission will be required (except by special arrangement with the PC chairs). Submissions must be in PDF, conform to the LNCS style, and be no longer than 15 PAGES. For formatting details see http://www.springer.de/comp/lncs/authors.html. ---------------------------------------------------------------------- PROGRAM COMMITTEE Chairs: * Robert Glück (U. of Copenhagen) * Michael Lowry (NASA) Members: * Don Batory (U. of Texas, USA) * Ira Baxter (Semantic Designs) * Cristiano Calcagno (Imperial College) * Prem Devanbu (U. of California at Davis) * Ulrich Eisenecker (U. of Leipzig) * Tom Ellman (Vassar College) * Robert Filman (NASA) * Zhenjiang Hu (U. of Tokyo) * Patricia Johann (Rutgers U.) * John Launchbury (Galois) * Anne-Françoise Le Meur (U. of Sci. and Tech. Lille) * Hong Mei (Peking U.) * Nicolas Rouquette (NASA) * William Scherlis (CMU) * Yannis Smaragdakis (Georgia Inst. of Tech.) * Walid Taha (Rice U.) * Todd Veldhuizen (Chalmers U. of Tech.) ORGANIZING COMMITTEE General Chair * Eugenio Moggi (Genova U.) Publicity Chair: * Eelco Visser (Utrecht U.) Workshops and Tutorials Chairs * Jeff Gray (U. of Alabama at Birmingham) * Andrew Malton (Waterloo U.) Local Arrangements Chair * Tarmo Uustalu (Inst. of Cybernetics, Tallinn) ----------------------------------------------------------------------

1 0

Re: [Template-haskell] types.
by Keean Schupke 20 Feb '05

20 Feb '05

Last mail seemed to get lost (think I forgot to CC it to the list): would this work with: $(something [d| f a = a + 1 |]) Such that I can reference the reified type of 'f' from inside 'something'. 'something' would be imported from another file. I am using ghc-6.4 Keean. Sean Seefried wrote: > > On 18/02/2005, at 8:11 PM, Keean Schupke wrote: > >> Is it possible to get at type information from TH? I am thinking of >> something >> like the following: >> >> f a = a + 1 >> >> {- ghc derives the type: f :: Integral a => a -> a -} >> >> Can I get at this derives type information? It would be very useful >> for the project I am working on... can I just reify the type of the >> function? >> > > The answer to this question is a little tricky - it's yes with a few > caveats. Firstly, the Q monad can be "run" in two contexts - within > the IO monad and with in the TcM monad of the GHC compiler. You can't > you `reify' to get type information in the former context. > Secondly, you can only reify the type of something that has been > imported from another module. No go on the reifying something > declared within the module you're reifying in. > > I have two pieces of sample code that demonstrate the Q monad being > run within the TcM monad and within the IO monad. The first one > works, the second doesn't. They are attached. > > These built in an old version of GHC 6.3. They should compile and run > in GHC 6.5 without *too* much difficulty although I haven't tested it. > > Cheers, > > Sean >

2 3

types.
by Keean Schupke 18 Feb '05

18 Feb '05

Is it possible to get at type information from TH? I am thinking of something like the following: f a = a + 1 {- ghc derives the type: f :: Integral a => a -> a -} Can I get at this derives type information? It would be very useful for the project I am working on... can I just reify the type of the function? Keean.

1 0