- template-haskell - Haskell.org

a couple of examples that cause Panic
by Isaac Jones 11 Apr '04

11 Apr '04

Greetings. Abe Egnor and I ran into a couple of panics in ghc-6.2 with TH in Debian: (ghci) > runQ (reifyDecl show) >>= print Actually, I think that breaks for any function in place of "show". Similarly: > module BugReport where > > data ObservedSound = ObservedSound > > foo = [d|instance Show ObservedSound where > show _ = "" |] Ian L. has mentioned that this may be fixed in CVS, but I figured I'd send it out to you before I forget. peace, isaac

1 0

RE: [Template-haskell] printf example out-of-sync
by Simon Peyton-Jones 08 Apr '04

08 Apr '04

Rats. The HEAD is ok, modulo a change from THSyntax to TH.Syntax in the library name. But it's annoying that 6.2 isn't right. I'm not sure we'll release another 6.2 so it may just stay like that. If someone would like to do the wiki examples that would be great. I guess to 6.2 for now. S | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Isaac Jones | Sent: 07 April 2004 21:40 | To: template-haskell | Subject: [Template-haskell] printf example out-of-sync | | Greetings! | | I noticed today that the printf example from the GHC 6.2 manual is out | of sync with at least the GHC 6.2 and libraries on my machine. I | updated the wiki page (for that example, but not the others, yet). | Since the purpose of the example is to get newbies over the | "confidence barrier", I thought I'd mention it ;) | | http://www.haskell.org/hawiki/TemplateHaskell | | | peace, | | isaac | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1

printf example out-of-sync
by Isaac Jones 07 Apr '04

07 Apr '04

Greetings! I noticed today that the printf example from the GHC 6.2 manual is out of sync with at least the GHC 6.2 and libraries on my machine. I updated the wiki page (for that example, but not the others, yet). Since the purpose of the example is to get newbies over the "confidence barrier", I thought I'd mention it ;) http://www.haskell.org/hawiki/TemplateHaskell peace, isaac

1 0

RE: mkName and qualified names
by Simon Peyton-Jones 07 Apr '04

07 Apr '04

1 0

FW: mkName and qualified names
by Simon Peyton-Jones 07 Apr '04

07 Apr '04

Suggestions from George -----Original Message----- From: George Russell [mailto:ger@informatik.uni-bremen.de] Sent: 07 April 2004 10:37 To: Simon Peyton-Jones Subject: Re: mkName and qualified names Hello Simon, incidentally you asked for priorities. Mine are (still) (1) spliced import declarations; (2) [ee| .. |] and [dd| .. |], which only attempt to resolve names when the splice is actually used. Both are important because I would like to be able to get rid of the remaining CPP directives in my code. best wishes, George

1 0

RE: mkName and qualified names
by Simon Peyton-Jones 06 Apr '04

06 Apr '04

Template Haskell folk I've fixed several bugs in Template Haskell, and made minor changes as follows * Two bugs reported by Duncan Coutts - do {d <- runQ $ [| let foo = bar where bar = 3 in foo |]; print d} used to panic - using newName "foo" twice gave rise to duplicate-binding warning * Make Language.Haskell.TH export dyn :: String -> ExpQ, as advertised in "note2" * Give an explicit export list to Language.Haskell.TH, so that it no longer exposes random helper functions from inside TH.Lib, say. I may have inadvertently hidden something useful, so please yell if so * Arrange that mkName (and hence dyn) understand qualified names. So dyn "Maybe.isJust" will now generate the qualified name, as you might expect. All of this in the HEAD only, of course. Keep pinging if there are bugs you trip over. And what is the top priority for improvement? Simon | -----Original Message----- | From: George Russell [mailto:ger@informatik.uni-bremen.de] | Sent: 02 April 2004 10:12 | To: Simon Peyton-Jones | Subject: Re: mkName and qualified names | | Simon Peyton-Jones wrote: | > Ah, indeed so. Apologies. | > | > The constructor Var is actually called VarE. | > | > And "dyn" should be defined but isn't. I was wrong to say the mkName | > won't do the job -- it will. But as you found, it doesn't work for | > qualified names. It probably should. (Or maybe "dyn" should but mkName | > should not, because dyn is only used for *occurrences* whereas mkName | > makes a name that you can use for binding too. It wouldn't make sense | > to say | > let n = mkName "A.x" in LamE (VarP n) (VarE n) | | Don't you bind a qualified name in a record or class declaration sometimes, | for example | x = M.A {M.b = True} | or | instance M.A B where | M.c = True | | Or is that something different? | | just checking, | | George

1 0

RE: mkName and qualified names
by Simon Peyton-Jones 02 Apr '04

02 Apr '04

Ah, indeed so. Apologies. The constructor Var is actually called VarE. And "dyn" should be defined but isn't. I was wrong to say the mkName won't do the job -- it will. But as you found, it doesn't work for qualified names. It probably should. (Or maybe "dyn" should but mkName should not, because dyn is only used for *occurrences* whereas mkName makes a name that you can use for binding too. It wouldn't make sense to say let n = mkName "A.x" in LamE (VarP n) (VarE n) ) So that's something I should fix. But meanwhile, the unqualified version works just fine mkTyConApp2 = $( varE . mkName $ "mkTyConApp" ) Simon | -----Original Message----- | From: George Russell [mailto:ger@informatik.uni-bremen.de] | Sent: 01 April 2004 16:03 | To: George Russell | Cc: Simon Peyton-Jones | Subject: Re: mkName and qualified names | | George Russell wrote: | > Simon Peyton-Jones wrote: | > | >> If you read "Notes about TH v2" you'll see that if you want something | >> that is *not* lexically scoped, you can use | >> $(dyn "x") | >> inside quotes. Section 4.4 dicssusses | > | > | > "dyn" doesn't seem to be exported by Language.Haskell.TH in the HEAD | > version. | | ... | | and while "Notes about TH v2" defines "dyn s = return (Var (mkName s))", | I can't do that because Language.Haskell.TH in the HEAD version doesn't | export Var either. I did use "varE" in my original example. | | best wishes, | | George

1 0

Final CFP: GPCE'04 (electronic submission open)
by Eelco Visser 08 Mar '04

08 Mar '04

FINAL CALL FOR PAPERS ---------------------------------------------------------------------- Third International Conference on Generative Programming and Component Engineering (GPCE'04) Vancouver, October 24-28, 2004 co-located with OOPSLA 2004 and ISMM 2004 http://gpce04.gpce.org ---------------------------------------------------------------------- ------------------------------------ Electronic submission is now open ------------------------------------ http://gpce.program-transformation.org ------------------------------------ Important Dates ------------------------------------ Pre-submission: March 12, 2004 Submission: March 19, 2004 ------------------------------------ Page limit is 20 pages LNCS format ------------------------------------ ------------------------------------ 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 prior 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 on the one hand, and the programming languages community on the other, in addition to supporting the original research goals of both the GCSE and the SAIG communities. We seek papers both in software engineering and in programming languages, and especially those that bridge the gap and are accessible to both communities at the same time. --- more information at http://gpce04.gpce.org

1 0

RE: [Template-haskell] Hygienic macros and lexical-scoping
by Simon Peyton-Jones 26 Feb '04

26 Feb '04

| > | using x val body = [| do { (var x) <- val; body; (var x).Dispose () } | > |] | > | // x is of type string | > | | > | [| \y -> do { $(using "x" [| x |]); f y |] | > | | > | wouldn't work, and one would have to use gensym by his own to get | > | > expected | > | > | sematics. | > | > I'm sorry, I didn't understand this at all. What is 'using x val body'? | > What is .Dispose()? Not Template Haskell certainly. | | Well, it supposed to be a function, which takes 'x' (of type string), 'val' | and 'body' (being expressions) and creates code which does: | - define local variable of name 'x' initialized with 'val' | - execute 'body' (it is assumed to have occurrences of 'x' inside, which | should be captured by local 'x' | - disposes 'x' (it has method 'Dispose', so I think its Haskell counterpart | would be calling function 'Dispose' on 'x') Ah. I thought 'using' was a keyword! OK, so it's like this: foo :: String -> Q Exp -> Q Exp -> Q Exp foo x val body = [| do { $(mkName x) <- $val; $body; dispose $(dyn x) } |] Here, mkName :: String -> Name dyn :: String -> Q Exp dyn s = return (Var (mkName s)) and I'm assuming an as-yet-unimplemented feature of TH which lets you splice a Name into a binding position (thus ($n <- ...) or (\$n -> ...)). The binding $(mkName x) certainly captures the occurrence $(dyn x). But you also want to capture some occurrences of 'x' in 'body'. Thus, consider foo "wug" [| 77 |] [| wug > 2 |] does the 'wug' in 'wug > 2' get captured by the (mkName "wug") binding? No, not in TH. The above call is statically rejected unless wug is already in scope. For example let wug = 88 in foo "wug" [| 77 |] [| wug > 2 |] And in this case, the 'wug > 2' is indissoubly bound to the 'wug = 88' binding. What if you *want* the 'wug > 2' to be bound un-hygienically to the (mkName "wug") binding? Then use 'dyn' thus let wug = 88 in foo "wug" [| 77 |] [| $(dyn "wug") > 2 |] Now, plainly, the wug=88 binding plays no role. | This can be implemented in TH with (dyn "x") which you mentioned, but if | 'body' is itself passed from another context and 'x' is introduced in | | f body = [| using "x" Foo $( [| do { dosomething x; body } |] ) |] | | then some external 'x' in original 'body' might get catched by dynamic | binding, which is not hygienic behavior. | | I'm aware that this can be workaround with manually creating 'x' with newName | and using this Name. Our decision to bind variables after macros expansion | makes it possible to handle such cases in other way. There are opposite | design goals, and I clearly see advantage of TH's one - bind to what you can | see, before any expansion. Nevertheless we will try another approach and | experiment with such system. I hope the above makes it clear that you can express either behaviour in TH. To be sure, the references to dynamically scoped things are inconvenient, as we see in $(dyn "wug") > 2, but at least there's a simple story to tell. | see, before any expansion. Nevertheless we will try another approach and | experiment with such system. Indeed -- this is a rather complex design space, so it's great to explore new parts of it. Simon

1 0

RE: [Template-haskell] Hygienic macros and lexical-scoping
by Simon Peyton-Jones 25 Feb '04

25 Feb '04

Kamil Thanks for your email. | My question is: when binding of variables is resolved? Is it during | translation of quotation, or maybe during expansion of $(...) where the above | code is used? Answer 1: Binding is resolved before any expansion or translation. So in \x -> $(f [| x |]) the occurrence of 'x' is bound indissolubly to the binding '\x', and you can tell that by looking at the source code, before expansion. So if 'f' was defined like this f :: Q Exp -> Q Exp f e = [| \x -> $e |] Then the expression \x -> $(f [| x |]) means the same as \x1 -> \x -> x1 Answer 2: In an extension that is implemented but not described in a published paper (but is described here http://research.microsoft.com/~simonpj/tmp/notes2.ps) we also support a sort of dynamic binding: \x -> $(f (dyn "x")) Here 'dyn' is a function with type dyn :: String -> Q Exp (dyn "x") is a variable that will bind to whatever "x" is in scope where that expression is spliced in. So the expression \x -> $(f (dyn "x")) means the same as \x1 -> \x -> x Notice that this dynamic binding always explicitly involves a string, like "x". You wouldn't expect (dyn "x") to bind indissolubly to the enclosing '\x'. | After reading the paper, I'm convinced that it's former case. But let's | consider: | using x val body = [| do { (var x) <- val; body; (var x).Dispose () } |] | // x is of type string | | [| \y -> do { $(using "x" [| x |]); f y |] | | wouldn't work, and one would have to use gensym by his own to get expected | sematics. I'm sorry, I didn't understand this at all. What is 'using x val body'? What is .Dispose()? Not Template Haskell certainly. | In our system we are shifting binding of variables from quotation translation | to macro expansion phase, so [| x |] can be "catched" inside 'using' | meta-function. Resolving of scoping is done after all executions of macros | are done. It involves quite complex algorithm to tag variables with place | where they come from - we are adapting Dybvig's algorithm into our system, so | we could use most flexible convention introduced by Scheme community. As I say above, TH supports both pre-expansion binding (via plain mentions of a variable), and post-expansion biding (via "dyn"). Whatever you choose to do, let me encourage you to give it a formal description. | As we discussed our design, there was some confusion if macros should | introduce new definitions into program. I noticed, that in Haskell it is done | by special keyword 'splice', and it's forbidden inside quotations. As we | decided to resolve names in late phase, we could introduce definitions in | arbitrary place. Yes, that's right. We discuss this in Section 8 of the above note. (But nested declaration splicing isn't yet implemented.) Some questions arise in that case: | Let's consider following macros (in Nemerle syntax, as I'm more used to it) | | using Foo; /// it introduces functions 'blah' and 'bar' variables | macro m() { <[ def bar() { 1 } ]> } | macro m'() { <[ m(); blah() + bar() ]> } | | does m'() generate | def bar_43 = 1; Foo.blah() + Foo.bar() | or | def bar_43 () { 1 }; Foo.blah() + bar_43() The most systematic story in TH would be that you get the former -- that's lexical scoping. You could get the latter by using (dyn "bar"). But, for top-level declarations, it's very inconvenient to use all the dyn stuff. So in TH we compromise: top level splices lexically shadow previous stuff, so you get the latter definition. We explicitly call this a hack (see section 8.2). Simon

2 1