- template-haskell - Haskell.org

Check whether item is instance of class
by S. Alexander Jacobson 08 Mar '05

08 Mar '05

I plan to write an XML serialization routine and would like to have per field behavior depend on whether the datatype of the field implements ToElement. In particular I want things that do not derive ToElement to be rendered as attributes and things that do implement ToElement to be rendered as child nodes. Is that possible using template haskell or do I have to add some sort of naming convention that signals it? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com

1 0

RE: [Template-haskell] Re: [Haskell] Proposal: Allow "\=" for field update in record update syntax
by Simon Peyton-Jones 07 Mar '05

07 Mar '05

What exactly is it that TH doesn't support, that you want? Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of S. Alexander Jacobson | Sent: 28 February 2005 10:32 | To: Sander Evers; template-haskell(a)haskell.org | Subject: [Template-haskell] Re: [Haskell] Proposal: Allow "\=" for field update in record update syntax | | 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 | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1

RE: [Template-haskell] Pattern bindings from TH2
by Simon Peyton-Jones 07 Mar '05

07 Mar '05

The ValD constructor, in the Dec type, lets you make pattern bindings. Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Einar Karttunen | Sent: 04 March 2005 09:48 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] Pattern bindings from TH2 | | Hello | | I am trying to make the following declaration work from TH2: | | (x,y) = (a,b) where (Foo a b) = foo | | but haven't found a way to make pattern bindings. Is there a way | to make such bindings? I am trying to construct the binding dynamically | with Language.Haskell.TH.Syntax as the code has to work for declaring | multiple kinds of pattern bindings. | | - Einar Karttunen | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

RE: [Haskell] Proposal: Allow "\=" for field update in record updatesyntax
by Simon Peyton-Jones 07 Mar '05

07 Mar '05

| That would be: | | (using 6.4 syntax) | | AppT (AppT (ConT (mkName "Bogus")) (ConT ''Int)) (ConT ''Char) Yes, it is a bit odd. In many ways it'd be better if the instance constructor was InstanceD Cxt Name [Type] [Dec] The Name would be the class name, the [Type] would be its args in the instance decl. I'm not sure why it is strange now. I'd change it, but it'd break people's code. TH folk: let me know if you'd prefer it changed in the next iteration. Simon

1 0

Pattern bindings from TH2
by Einar Karttunen 04 Mar '05

04 Mar '05

Hello I am trying to make the following declaration work from TH2: (x,y) = (a,b) where (Foo a b) = foo but haven't found a way to make pattern bindings. Is there a way to make such bindings? I am trying to construct the binding dynamically with Language.Haskell.TH.Syntax as the code has to work for declaring multiple kinds of pattern bindings. - Einar Karttunen

1 0

RE: template-haskell
by Simon Peyton-Jones 03 Mar '05

03 Mar '05

| TH already has type syntax, as I can examine: | | [| | f :: Num a => a -> a | f a = a + 1 | |] | | So I am not sure I understand which bit of syntax is missing? You'd like to be able to look at the Name 'a' and ask its type. Indeed, you'd like to know the type of an arbitrary sub-expression. So the change I had in mind was to attach a Type to a Name. | \x -> ($(do_something [| \y -> x |]), x::Int) | | The type could be " a -> a " ... IE just looking at the anonymous | functions it is fully polymorphic. | | You could veiw this as the most specific type available without | information from outside the meta-quote, which is the only definition | that makes sense to me at the moment. So if you had \(x::Int) -> ($(do_something [| \y -> x |]) you still want to get "a->a"? You definitely don't want to ignore the types of things defined outside -- think of 'map' and (+)! And what is this 'a' anyway? It's not bound anywhere. One can make pragmatic decisions about these things, but I'd prefer a principled approach.

2 1

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