- template-haskell - Haskell.org

instance of Lift for Exp
by Duncan Coutts 08 Jun '04

08 Jun '04

Hi all, the Exp type is not an instance of the Lift class. This is the sensible thing most of the time so that you do not lift an expression when you meant to splice it instead. However in my experience it's sometimes useful (particularly when writing code that generates code), so attached is a module which makes it an instance. Like Text.Show.Functions, you should only import it if you want it, not import it by default. If people find this useful, I'd be quite happy to have it added to the standard GHC TH libs. I've named it Language.Haskell.TH.LiftExp and released it under GHC's BSD-style licence. Issues: * At the moment it also exports instances for Ratio, Maybe, PackedString, (,) and (,,). In my opinion these instances should be exported from Language.Haskell.TH already in which case they could be deleted from this module. (Exporting the instance for PackedString and Ratio is not strictly necessary and perhaps not desirable.) * The encoding for unboxed integers is not pleasant. (Unboxed Ints are used in the definition of Name). If anyone can find a more straightforward encoding please tell me. Duncan

1 0

RE: [Template-haskell] TH preprocessing
by Simon Peyton-Jones 25 May '04

25 May '04

| I wouldn't mind having a look at this. If you could tell me a little | about the purpose of the dictionary stuff I'd be willing to have a go | at adding this feature. Great! GHC's type checker generates a *translated program* as well as a *type*. The translated program has explicit type abstractions and applications (in the style of System F), as well as explicit dictionary abstractions and applications. The latter is part of the "dictionary-passing" or "evidence-passing" way of implementing type classes, which you can find described in any paper about type classes. Rather than attempt a half-baked explanation, you might want to talk to Don or Manuel, both of whom understand the translation idea. (At least, I know Manuel does.) In Template Haskell, the typechecker also expands splices, so the translated program has the expanded version. The idea, then, would be to print out the type-checked program, as Haskell source that could be stuffed back into GHC right at the front. The main issues I can think of are these: 1. The pretty-printer for HsSyn does not print precisely Haskell syntax. This should be easy to fix. 2. To print Haskell source, you need to remove the extra stuff inserted by the translation. I suggest this is a HsSyn->HsSyn pass, to avoid writing a second pretty-printer. Many of the translated bits are flagged by special HsSyn constructors (e.g. DictLam). I'm not certain that all are. 3. One particular construct, AbsBinds, is what a binding group is translated to. There you will find dictionary bindings and programmer bindings mixed up together. I think the former are all VarMonoBinds while the latter never are, so I think you can disentangle them fine. I'm happy to help you, but the easiest way to do so is probably to create a branch in ghc/compiler (only) so that I can see what you've done and fiddle where necessary. Manuel knows how to do that. Make sure you *tag* the tree just before you *branch* it, so that we can subsequently merge easily cd ghc/compiler cvs update cvs tag th-print-branch-point cvs tag -b th-print-branch Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Sean Seefried | Sent: 21 May 2004 05:30 | To: Template Haskell Mailing List | Subject: Re: [Template-haskell] TH preprocessing | | | On 10/05/2004, at 6:29 PM, Simon Peyton-Jones wrote: | | > Not at present. It's actually a little trickier than it looks, because | > the post-type-checked program (with the splices expanded) has | > dictionary | > stuff floating around, and it's not entirely straightforward to convert | > it back to vanilla source Haskell. | > You're right it would be useful. I think it's feasible with a bit of | > work. I'd be willing to help anyone who wanted to undertake it. | > | | I wouldn't mind having a look at this. If you could tell me a little | about the purpose of the dictionary stuff I'd be willing to have a go | at adding this feature. | | Sean | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

RE: [Template-haskell] TH preprocessing
by Simon Peyton-Jones 21 May '04

21 May '04

Not at present. It's actually a little trickier than it looks, because the post-type-checked program (with the splices expanded) has dictionary stuff floating around, and it's not entirely straightforward to convert it back to vanilla source Haskell. You're right it would be useful. I think it's feasible with a bit of work. I'd be willing to help anyone who wanted to undertake it. Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Wolfgang Jeltsch | Sent: 09 May 2004 23:14 | To: Template Haskell Mailing List | Subject: [Template-haskell] TH preprocessing | | Hello, | | is there a program which takes a Haskell source file, compiles it with | -ddump-splices, replaces the splices in the source file with the dumped code | and outputs the resulting file? I'd like such a tool since I think it would | it make possible to use TH with Hugs. You would preprocess each file with | this program and feed Hugs with the resulting files. | | Wolfgang | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

3 2

RE: [Template-haskell] pprDec bug
by Simon Peyton-Jones 20 May '04

20 May '04

That would make sense for stuff that was printed by GHC itself, but what argument would you like to give to ppr pprDec :: ??? -> Dec -> Doc The ??? is presumably some specification for "what is in scope in this module". What type is this? Since you, the programmer, are calling it, where are you going to get that argument from? Where GHC prints stuff (e.g. -ddump-splices), life would be easier. Simon | -----Original Message----- | From: Duncan Coutts [mailto:duncan.coutts@worcester.oxford.ac.uk] | Sent: 19 May 2004 10:31 | To: Simon Peyton-Jones | Cc: Template Haskell List | Subject: RE: [Template-haskell] pprDec bug | | On Wed, 2004-05-19 at 08:44, Simon Peyton-Jones wrote: | > | Is there an easy way to transform the declaration to use the | > | short forms of type names, e.g. "Int" instead of "GHC.Base:Int"? | > | > That's harder, because it's not clear what qualifications to omit. All? | > But then the program might be ambiguous. I guess this is so you can | > feed it back into GHC, right? You can always import GHC.Base, | > and then you'll be fine. | | How about a pretty printer that is given a module context so is can | print the least-qualified identifiers possible given the identifiers in | scope in that module. I guess this is what ghc does when it prints its | error messages. | | eg (in the Q monad): | module <- currentModule | pprExpInModuleContext module | | Then not only will the code be valid to feed back to the compiler, but | it'll also be readable! (I've been looking at too much machine generated | code recently :-) ) | | Duncan

1 0

RE: [Template-haskell] pprDec bug
by Simon Peyton-Jones 19 May '04

19 May '04

| I'm using GHCi version 6.2.1 under Cygwin. I'm trying to implement a | compiler that translates a DSL into Haskell; I'd like to build the | structure incrementally and then use the pretty printer to output the | target code. However, the pretty printer does not always produce | valid output; sometimes needed parentheses are lacking, as in: | | Main> pprDec $ DataD [] "M" [] [NormalC "M" [(NotStrict, AppT (ConT Maybe) (ConT "Int"))]] [] | data M = M Maybe Int Good point. I've fixed this in the HEAD, and on the stable branch, so it'll be in 6.2.2 Prelude Language.Haskell.TH> ppr $ DataD [] (mkName "M") [] [NormalC (mkName "M") [(NotStrict, AppT (ConT ''Maybe) (ConT ''Int))]] [] data M = M (Data.Maybe.Maybe GHC.Base.Int) | Related question: I've defined a utility function | | > pdq decq = runQ decq >>= mapM_ print . map pprDec | | so I can pretty-print declarations in code brackets, viz.: | | Main> pdq [d| data M = M (Maybe Int) |] | | Is there an easy way to transform the declaration to use the | short forms of type names, e.g. "Int" instead of "GHC.Base:Int"? That's harder, because it's not clear what qualifications to omit. All? But then the program might be ambiguous. I guess this is so you can feed it back into GHC, right? You can always import GHC.Base, and then you'll be fine. Still, one could imagine a flag to pprDec (or, more generally, to ppr) that, say, printed all top-level names unqualified. But that'd require a bit of re-plumbing in the pretty-printer to get the flag to the right place. Simon

2 1

pprDec bug
by Daniel Brown 18 May '04

18 May '04

I'm using GHCi version 6.2.1 under Cygwin. I'm trying to implement a compiler that translates a DSL into Haskell; I'd like to build the structure incrementally and then use the pretty printer to output the target code. However, the pretty printer does not always produce valid output; sometimes needed parentheses are lacking, as in: Main> pprDec $ DataD [] "M" [] [NormalC "M" [(NotStrict, AppT (ConT Maybe) (ConT "Int"))]] [] data M = M Maybe Int Related question: I've defined a utility function > pdq decq = runQ decq >>= mapM_ print . map pprDec so I can pretty-print declarations in code brackets, viz.: Main> pdq [d| data M = M (Maybe Int) |] Is there an easy way to transform the declaration to use the short forms of type names, e.g. "Int" instead of "GHC.Base:Int"? -- Dan.

1 0

RE: [Template-haskell] TH preprocessing
by Simon Peyton-Jones 11 May '04

11 May '04

It's definitely possible. I don't think it's dead easy. As I say, I would be happy to help anyone who wanted to try. Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Wolfgang Jeltsch | Sent: 10 May 2004 20:55 | To: Template Haskell Mailing List | Subject: Re: [Template-haskell] TH preprocessing | | Am Montag, 10. Mai 2004 10:29 schrieben Sie: | > Not at present. It's actually a little trickier than it looks, because | > the post-type-checked program (with the splices expanded) has dictionary | > stuff floating around, and it's not entirely straightforward to convert | > it back to vanilla source Haskell. | | If I understood TH correctly, the expressions after the "splice operator" $ | describe vanilla source Haskell. And I assumed that it's this vanilla source | code which -ddump-splices outputs. (I've never checked this myself.) So why | isn't it possible to replace the splice parts in the *original* Haskell | source file with the outputs of -ddump-splices? This could be done via some | search and replace at the text level though this is, of course, not very | elegant. | | > [...] | | Wolfgang | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

RE: [Template-haskell] Templates + FFI + shared libs = segfault?
by Simon Marlow 10 May '04

10 May '04

On 07 May 2004 00:09, Robert Dockins wrote: > That appears to be the case. ghci crashes just loading the .so > (listings below). After playing around, the problem seems to be with > loading the dependancies. If I load -lqt also (very carefully), then > ghci doesn't crash, and, in fact, the origninal TH module also loads > and works with the correct command line. In short here is the scoop: > > > ghci -lsmokeqt segfault > ghci -lqt -lsmokeqt can't find .so > ghci -L/usr/qt/3/lib -lqt -lsmokeqt works! > ghci -L/usr/qt/3/lib -lsmokeqt -lqt segfaults > ghci -lqt can't find .so > ghci -L/usr/qt/3/lib -lqt works Before we dig into this, could you try a simple C program which just calls dlopen() on smokeqt, and see if that fails? It looks from your diagnosis that this is perhaps not related to GHC at all, but something between the dynamic linker and smoke. > So, it appears that libqt.so (or libqt-mt.so also works) must be > loaded before libsmokeqt.so. The same thing occurs when I insert the > above options into the command line to compile my TH module. > > I am attaching output from LD_DEBUG=files listings from three > different situations > > 1) ldrun.txt output from a simple program which uses smoke > 2) ghcismokeqt.txt output from ghci -lsmokeqt > 3) ghciqtsmokeqt.txt output from ghci -L/usr/qt/3/lib -lqt-mt > -lsmokeqt > > 2) is the interesting one. It cuts off after calling init on > libsmokeqt.so. It also contains an error while binding the symbol > 'pthread_key_create' in the libGL module, which looks very odd. I can > only assume this is related somehow. The error in question looks > like: > > 12500: /usr/X11R6/lib/libGL.so.1: error: relocation error: > undefined symbol: pthread_key_create (fatal) > > This error does not occur in 1) nor in 3). Perhaps the linker is failing to load a dependency? Cheers, Simon

2 1

TH preprocessing
by Wolfgang Jeltsch 09 May '04

09 May '04

Hello, is there a program which takes a Haskell source file, compiles it with -ddump-splices, replaces the splices in the source file with the dumped code and outputs the resulting file? I'd like such a tool since I think it would it make possible to use TH with Hugs. You would preprocess each file with this program and feed Hugs with the resulting files. Wolfgang

1 0

RE: [Template-haskell] Templates + FFI + shared libs = segfault?
by Simon Peyton-Jones 06 May '04

06 May '04

Robert You seem to have stumbled on a bug somewhere involved in dynamic linking. I rather doubt it has anything to do with TH. Step 1 is to separate out Template Haskell. Does this happen with ghci? ghci -lsmokeqt then do some ghci stuff. It'd help if you could crash it that way. Next, we'll need to be able to reproduce it here. Can you boil out the smallest thing that demonstrates the problem and send it, with instructions? We'll need to get smokeqt, I suppose. It probably won't be identical to yours, because our Linux will be slightly different. I hope that doesn't hide the problem. Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Robert Dockins | Sent: 30 April 2004 00:51 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] Templates + FFI + shared libs = segfault? | | 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

2 1