- template-haskell - Haskell.org

RE: [Template-haskell] a couple of examples that cause Panic
by Simon Peyton-Jones 06 May '04

06 May '04

Yes, these are ok in the HEAD, thanks (modulo various renamings) Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Isaac Jones | Sent: 11 April 2004 20:07 | To: template-haskell | Subject: [Template-haskell] a couple of examples that cause Panic | | 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 | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

FW: Missing TH exports
by Simon Peyton-Jones 04 May '04

04 May '04

Ian Was there any reason to omit these? Care to add them? Simon -----Original Message----- From: glasgow-haskell-bugs-bounces(a)haskell.org [mailto:glasgow-haskell-bugs-bounces@haskell.org] On Behalf Of Duncan Coutts Sent: 28 April 2004 14:41 To: glasgow-haskell-bugs(a)haskell.org Subject: Missing TH exports In the past month or two a few convenience functions from Language.Haskell.TH.Lib seem to have been dropped from the export list for Language.Haskell.TH. This is in ghc cvs HEAD. Just wondering if this was an oversight or if there was a reason. The ones I noticed are: forallT, listT, infixC Duncan _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs(a)haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

1 0

Templates + FFI + shared libs = segfault?
by Robert Dockins 30 Apr '04

30 Apr '04

I forgot to mention, GHC version: ghc-6.3.20040426 Smoke version : CVS from 20040429 (although I had the same behavior from the kdebindings-3.2.1 package) Linux 2.6.5 gcc version 3.3.2 20031218 glibc 2.3.2 Qt 3.3.0 Robert Dockins

1 0

Templates + FFI + shared libs = segfault?
by Robert Dockins 30 Apr '04

30 Apr '04

Greetings, I'm new to Template Haskell and I'm working on a project to get my feet wet. I'm working on bindings for Qt using the smoke library. (Some info about smoke here:http://developer.kde.org/language-bindings/smoke/ ). Smoke is essentially a language independant binding library with some introspection built in. So, I'm trying to use the introspection features of smoke + template haskell to generate type, class and instance declarations to model the Qt class structure. The problem occurs when I try to link to the smoke shared libray at splice time. When I do, ghc segfaults: ghc -c -fffi -fth smokeglue.o -lsmokeqt testtemp.hs Loading package base ... linking ... done. Loading object (static) smokeglue.o ... done Loading object (dynamic) smokeqt ... done Segmentation fault Now this next one is really weird. The code in the next listing doesn't have any symbols to resolve; it doesn't even use FFI, but it still segfaults when I link to the library (although apparently in a different place?) : $ ghc --make -fth main.hs Chasing modules from: main.hs Skipping Template ( ./Template.hs, ./Template.o ) Compiling Main ( main.hs, main.o ) Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Loading package template-haskell ... linking ... done. Linking ... $ touch *.hs $ ghc --make -fth -lsmokeqt main.hs Chasing modules from: main.hs Compiling Template ( ./Template.hs, ./Template.o ) Compiling Main ( main.hs, main.o ) Loading package base ... linking ... done. Loading object (dynamic) smokeqt ... done final link ... done Loading package haskell98 ... linking ... done. Loading package template-haskell ... linking ... done. Segmentation fault Other shared libs work though: $ ghc --make -fth -lxine main.hs Chasing modules from: main.hs Skipping Template ( ./Template.hs, ./Template.o ) Compiling Main ( main.hs, main.o ) Loading package base ... linking ... done. Loading object (dynamic) xine ... done final link ... done Loading package haskell98 ... linking ... done. Loading package template-haskell ... linking ... done. Linking ... I haven't been able to find any other libs that cause ghc to segfault like this; it appears just to not like this one. Also, if I link against the lib normally (ie, not during a splice) it works, and the resulting executable works as well. My guess is that something isn't quite right with the code that links shared libraries at splice time, but... its just a guess. Any ideas? Thanks, Robert Dockins

1 0

RE: [Template-haskell] Some ideas
by Simon Peyton-Jones 28 Apr '04

28 Apr '04

| Using this we could say (on the toplevel of a module): | addDeriving ("Fold", deriveFold) | | Note that this would let us derive not only instances but new | functions or even new data types. Mega Awsome! Can't you do this already? data T = MkT Int $(deriveFold 'T) where deriveFold :: TH.Name -> Q [Dec] | Splicing pragmas | =============== | | It would be nice to be able to splice in compiler pragmas. For example | if one writes a TH module for deriving folds and builds one would like | to generate rules pragmas so that GHC can fuse these functions when | they are used. Generating self-optimising code :). | | Concretely one would add a constructor to the Dec data type. Something | like this: | | data Dec = ... | | PragmaD Pragma Yes, more and more GHC extensions are creeping into TH, and maybe that's OK. It is tiresome, but not difficult, to extend the abstract syntax and to-and-fro conversions. Ian Lynagh has become quite good at it. OK with me! | >From Meta Haskell to Meta X | =========================== I don't know how to make a good job of this, but it seems like a good problem for someone to study. The thing is that language X has scoping and typing rules that are different to Haskell's. How to express them? It's not just syntax! Simon

2 1

Some ideas
by Josef Svenningsson 27 Apr '04

27 Apr '04

Hi TH'ers, This weekend I just wrote my first "Hello World" in TH. Meta programming is great fun! While hacking away a number of ideas popped up in my head about ways of extending TH to make it even cooler. I realise this is not the first mail in that category, there seems to be an endless number of things one could possibly add to TH. Anyway, read as far as you like, it's a pretty long mail. Derving ======= Is would be nice to make the deriving mechanism programmable with Template Haskell. The problem is when the typechecker finds a deriving clause for something it doesn't recognise, where should it look? What we need is a way to register presence of a new deriving gizmo to GHC, a new language construct in Template Haskell. Let's call it 'addDeriving'. It would be something which could only be invoked on the toplevel of a module. What type should it have? Well since it's a language construct I don't know what return type it should have but it's argument type should be something like this: (String, Dec -> Q [Dec]). The first argument is the name we refer to in the deriving clause. For example ' ... deriving Fold'. Does it have to be upper case? I don't know but I don't think so. The second argument tells GHC how the deriving works. GHC supplies the data type declaration and gets a bunch of declarations back. Using this we could say (on the toplevel of a module): addDeriving ("Fold", deriveFold) Note that this would let us derive not only instances but new functions or even new data types. Mega Awsome! Splicing pragmas =============== It would be nice to be able to splice in compiler pragmas. For example if one writes a TH module for deriving folds and builds one would like to generate rules pragmas so that GHC can fuse these functions when they are used. Generating self-optimising code :). Concretely one would add a constructor to the Dec data type. Something like this: data Dec = ... | PragmaD Pragma data Pragma = RulePr String Phase [(String,Maybe Type)] Exp Exp | InlinePr String | NoInlinePr String | Specialize String Type data Phase = Always | Upto Int | From Int Perhaps the deprecated pragma also makes sense. The other pragmas doesn't seem to make sense here. This is ofcourse very GHC specific but so is TH. >From Meta Haskell to Meta X =========================== Template Meta Haskell is a language which is a very nice meta language for Haskell. It has some really nice quotation syntax for creating abstract Haskell syntax using Haskell's concrete syntax. But we all know that Haskell is a great meta language for any language, not just for itself. It is in fact what Haskell does best if you ask me. So it would be nice if we could extend this quotation mechanism to work for any language. Here's a proposal for doing more or less that. It is very much inspired by a very similar functionality in SML/NJ. See: http://www.smlnj.org/doc/quote.html The idea is this: we want to generalise the Oxford brackets (i.e. [| |]) so that they are overloaded. Here's an example: id :: ObjectLang a => a id = [| \x -> x |] Since we in general want to generate new names a better type would perhaps be: id :: ObjectLang a => Q a The real advantage of having this is ofcourse when we use the splicing mechanism inside the quotation. Like this: mkLet :: ObjectLang a => a -> Q a mkLet body = [| let x = $body in x |] The tricky thing is how to handle this in the parser. In SML/NJ they translate the quotation syntax to the following data type: data Frag a = Quote String | AntiQuote a According to this scheme Oxford brackets would be translated into something of type [Frag a]. For example: formula a = [| $a == > A |] would be translated to formula a = [Quote " ", AntiQuote a, Quote " ==> A "] Fo far this is exactly SML/NJ modulo syntax and some names. My idea is that we stick in a little parser function in front of the list. This function should be appropriately overloaded. Say we add the following class: class ObjectLang a where parseOL :: [Frag a] -> Q a Then our example above would be translated into: formula a = parseOL [Quote " ", AntiQuote a, Quote " ==> A "] Jolly useful! Adding this mechanism to TH will probably mess up the parser pretty badly. But I still think it is worth thinking through. This extension could be rather useful after all. One thing to think of is what to do with other syntactic categories. In TH we have [d| |] for declarations, [p| |] for patterns and so forth. Should there be a fixed number of syntactic categories for all object languages? Hopefully not but how would you lift the restriction? A long mail. Thank you for reading it all to the end. I hope you got something out of it. If you're either Simon PJ och Tim S then please consider the implications of what I've suggested. It would be nice to know if any of this makes sense/is doable. Cheers and happy meta programming, /Josef

1 0

RE: [Template-haskell] two things I wanted from TH today
by Simon Peyton-Jones 23 Apr '04

23 Apr '04

| > But it doesn't look like Pattern Guards are available in THSyntax yet. The question is whether we want THSyntax to absorb all GHC extensions. I guess the answer does seem to be 'yes, on demand' because the kind of people who use TH also seem to be the kind of people who use GHC extensions! Re Ian's alternatives below, my own preference would be for (1) just because it's simple and direct. I think that TH users are savvy enough to absorb THSyntax changes without much pain, so backward compatibility isn't too big an issue. Esp since the HEAD contains lots of changes anyway. Simon | Hmm, we currently have | | data Body = GuardedB [(Exp,Exp)] | | NormalB Exp | | It looks like we would want either | | ----- 1 | data Body = GuardedB [(Guard,Exp)] | | NormalB Exp | | data Guard = NormalG Exp | | PatG [Stmt] | ----- | | or | | ----- 2 | data Body = GuardedB [(Exp,Exp)] | | PatGuardedB [(Guard,Exp)] | | NormalB Exp | | data Guard = NormalG Exp | | PatG [Stmt] | ----- | | or | | ----- 3 | data Body = GuardedB [(Exp,Exp)] | | PatGuardedB [([Stmt],Exp)] | | NormalB Exp | ----- | | 1 is the simplest overall, but I think it would set a bad precedent as | we wouldn't want future extensions to cause TH programs to break. | | 2 and 3 have the advantage that Haskell98+TH users can pretend nothing | happened. I think I prefer 2 over 3 as it's simpler to see what happens | when a GuardedB and PatGuardedB are concatenated. | | So I propose option 2. Does anyone disagree?

2 1

RE: [Template-haskell] mysterious type inference problem in splice
by Simon Peyton-Jones 20 Apr '04

20 Apr '04

Consider what $(idwrap2 i1) expands to. It's just as if you wrote i1 = [| 1 |] $( [| idexp $i1 |] ) Inlining i1 gives $( [| idexp 1 |] ) and indeed idexp expects an ExpQ (think syntax tree) whereas 1 is plainly just a number. In general you'd be much better off using the quotation notation unless you absolutely have to use appE and friends, for reasons described in the paper. http://research.microsoft.com/%7Esimonpj/papers/meta-haskell Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Daniel Brown | Sent: 17 April 2004 04:58 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] mysterious type inference problem in splice | | I'm using Template Haskell for the first time, trying to do some code | manipulation, and I'm getting some error messages I don't understand. | In the code below, idwrap[01] behave as expected, but idwrap2 does not | work the same way: | | *Q> $(idwrap0 i1) | 1 | *Q> $(idwrap1 i1) | 1 | *Q> $(idwrap2 i1) | | <interactive>:1: | No instance for (Num ExpQ) | arising from the literal `1' at <interactive>:1 | In the first argument of `idexp', namely `1' | In the definition of `it': it = $[splice](idwrap2 i1) | | What's going on here? Why does the system want to prove (Num ExpQ)? (I | should add that I'm also new to GHC, though I have used Hugs a fair | amount.) | | -- Dan. | | ------------------------------------------------------------------------ | | module Q where | | import Language.Haskell.THSyntax | | idq = id | idexp = id :: ExpQ -> ExpQ | | idwrap0 e = appE (varE "GHC.Base:id") e | idwrap1 e = appE (varE "Q:idq") e | idwrap2 e = appE (varE "Q:idexp") e | | i1 = litE (integerL 1) | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

mysterious type inference problem in splice
by Daniel Brown 17 Apr '04

17 Apr '04

I'm using Template Haskell for the first time, trying to do some code manipulation, and I'm getting some error messages I don't understand. In the code below, idwrap[01] behave as expected, but idwrap2 does not work the same way: *Q> $(idwrap0 i1) 1 *Q> $(idwrap1 i1) 1 *Q> $(idwrap2 i1) <interactive>:1: No instance for (Num ExpQ) arising from the literal `1' at <interactive>:1 In the first argument of `idexp', namely `1' In the definition of `it': it = $[splice](idwrap2 i1) What's going on here? Why does the system want to prove (Num ExpQ)? (I should add that I'm also new to GHC, though I have used Hugs a fair amount.) -- Dan. ------------------------------------------------------------------------ module Q where import Language.Haskell.THSyntax idq = id idexp = id :: ExpQ -> ExpQ idwrap0 e = appE (varE "GHC.Base:id") e idwrap1 e = appE (varE "Q:idq") e idwrap2 e = appE (varE "Q:idexp") e i1 = litE (integerL 1)

1 0

two things I wanted from TH today
by Isaac Jones 16 Apr '04

16 Apr '04

Greetings. FYI, I ran into two problems while trying to write something in TH today that I thought I'd mention. I'm not saying that these are vital features, but that this is perhaps a vote for these :) I wanted to write code to generate a function like this: > foo :: Dynamic -> String > foo val > | Just (a::String) <- fromDynamic val > = a > | Just (a::Int) <- fromDynamic val > = show a > | Just (a::Float) <- fromDynamic val > = show a But it doesn't look like Pattern Guards are available in THSyntax yet. I bravely started writing something to do this, but gave up, as did someone else on IRC, since what I really want is a lot simpler. So then I decided to settle for code like this: > foo'' :: Dynamic -> String > foo'' val > = case fromDynamic val of > Just (a::String) -> a > _ -> (case fromDynamic val of > Just (a::Int) -> show a > _ -> (case fromDynamic val of > Just (a::Float) -> show a > _ -> "")) But then I found that type signatures on patterns also aren't available. In the end, I expect to be able to generate code like this: > foo' :: Dynamic -> String > foo' val > = case fromDynamic val of > Just a -> (a::String) > _ -> (case fromDynamic val of > Just a -> show (a::Int) > _ -> (case fromDynamic val of > Just a -> show (a::Float) > _ -> "")) peace, isaac p.s. As an aside, pattern guards are cool! I've been avoiding almost all extensions in my work projects, and am temporarily lifting that self-imposed restriction. I've learned some neat stuff in the past week :)

2 1