September 2003 - template-haskell

problem with quasi-quoting instance declaration
by Ganesh Sittampalam 11 Sep '03

11 Sep '03

Using 6.0.1 or the 20030903 CVS snapshot: ghc-6.1: panic! (the `impossible' happened, GHC version 6.1): Failed binder lookup: GHCziShow.show {- v r4H -} If I try to compile the following code. Commenting out the line defining show (but not the instance line itself) makes the error go away. Cheers, Ganesh module TH2 where code = [d| data Foo = Foo instance Show Foo where show Foo = "foo" |]

1 0

RE: [Template-haskell] Using a Typ as a Type
by Simon Peyton-Jones 04 Sep '03

04 Sep '03

OK, I see a bit better now. One question you raise (implicitly) is whether you can have splices inside splices: y = [| 4+5 |] f x = $(h $y) TH doesn't currently allow this, but there's no difficulty in principle. To see this, just substitute for y: f x = $(h $[| 4+5 |]) = $(h (4+5)) But you also try something that really won't work: f x = $x This is ill staged. TH must *run* the top-level splices. It can't run $x because it doesn't know x's value yet. So in your example, the line let x = f "1" :: $typ is ill-staged because TH can't run $typ, because type is lambda bound. I could just about imagine the following. Suppose your 'generate' was a TH function that *generated a TH function*. So the entire body of 'generate' is quoted. Then I could just about imagine how it might work. The type of generate would look something like | generate :: String -> Q Typ -> Q (Expr (Q [Dec])) (I'm imagining here that Expr is parameterised, which it isn't, but it helps documentation to say (Expr t) means an Expr of type t.) Then a call to generate would look like $($(generate ..)) It would execute by running generate to produce a TH program (essentially inlining only), typechecking that (this is where the overloading you want would be resolved) and then running it. A consequence would be that the TH data types (Expr, Dec etc) would need to get extra constructors to represent quotes, splices etc. Bottom line: today, definitely no. But I hadn't realised before that there could, just, be some benefit to repeated splices like $($(generate...)). I wonder if anyone else has come across this need? Simon | -----Original Message----- | From: Alastair Reid [mailto:alastair@reid-consulting-uk.ltd.uk] | Sent: 03 September 2003 16:06 | To: Simon Peyton-Jones; Alastair Reid; template-haskell(a)haskell.org | Subject: Re: [Template-haskell] Using a Typ as a Type | | > Perhaps the thing to | > do is to give a simple but concrete example of what you'd like to do. | | The following is a simplified version of what I tried to do in Template | Greencard. | | -- a new class | class X a where | -- member parameterized on result type | f :: String -> a | -- member parameterized by argument type | ctype :: a -> String | | -- instances for old types | instance X Int where | f = read | ctype _ = "HsInt" -- FFI-defined C type corresponding to Int | | -- instances for freshly defined types | newtype T = T Int | deriving Show -- included to make the example work | | instance X T where | f s = T (read s) | g (T x) = g x | | generate :: String -> Q Typ -> Q [Dec] | generate nm typ = do | | -- The next line contains the type splice. | -- Note that it is used to perform a compile-time dictionary | -- lookup not a runtime lookup. | -- I'm not wedded | let x = f "1" :: $typ | | -- Generate C code (should be written to a file, not stdout) | -- Code generated depends on type argument | qIO (putStrLn (ctype x ++ " " ++ nm ++ " = " ++ show x ++ ";\n") | | -- return a variable definition. | -- again, the definition returned depends on the type | -- because it uses 'x' which was produced as a result of | -- the compile-time dictionary lookup. | [d| $nm = $(literal x) |] | | | > Remember, the execution of TH program can be described by ordinary | > rewriting rules (replace the LHS of a function by the RHS of the | > function, suitably instantiated), augmented with the one extra rule | > $[| e |] = e | | Should this apply to types as well? | | -- | Alastair |

1 0

RE: [Template-haskell] Using a Typ as a Type
by Simon Peyton-Jones 04 Sep '03

04 Sep '03

Tim and I are working on this very thing right now. Stay tuned Simon | -----Original Message----- | From: Alastair Reid [mailto:alastair@reid-consulting-uk.ltd.uk] | Sent: 03 September 2003 16:17 | To: Simon Peyton-Jones; Alastair Reid; template-haskell(a)haskell.org | Subject: Re: [Template-haskell] Using a Typ as a Type | | On Wednesday 03 September 2003 2:19 pm, Simon Peyton-Jones wrote: | > | > TH doesn't support type splices today; that's one of the things I'm | > | > actively working on. But I'm not sure if this is what you meant. | | btw Something that would be very nice is if $ could be used to splice patterns | and declarations as well as expressions so that I could write: | | foo :: String -> Q [Dec] | foo x = [| \ $(pat x) -> $(var x) |] | | or | | bar :: Q Expr -> Q Dec -> Q [Dec] | bar e binding = [| let $binding in $e |] | | These examples aren't that compelling but I've had to code round not being | able to write code like this lots of times. | | -- | Alastair | | ps This is quite independent of my request for type splices. The above makes | it easier to write what you can already write whereas type splices extend the | power of TH to let you write things that aren't possible at the moment. | |

1 0

RE: [Template-haskell] Profiling with Template Haskell
by Simon Peyton-Jones 03 Sep '03

03 Sep '03

| The issue is this: | | how can one compile a program that uses TH | so that the resulting executable is profiled | | I'll call | C-code is code that runs at compile time | R-code is code that runs at runtime | | We aren't trying to profile C-code, only R-code. Further ruminations, following discussion with Simon M. Assume that a module M contains a mixture of C-code and R-code (which in general it can). Compile it both ways: ghc -c M.hs (generates M.o non-profiled, M.hi) ghc -c -prof -O M.hs -o C.p_o (generates M.p_o profiled, M.hi again) Now suppose module A is like this: module A where { import M( f ) $(f 3) h x = f x } A contains only R-code, so it need not be compiled without -prof. When we say ghc -c -prof -O A.hs GHC will load M.hi, then dynamically link the non-profiled M.o, and run it. Later you link A.o and M.p_o, and all should be well. NOTE that M.hi serves to describe both M.o and M.p_o. That's ok, because all the TH part needs (when typechecking $(f 3)) is the type of f, and that's the same in both M.o and M.p_o. It's important to compile M.hs with -prof *second* so that the profiled .hi file is the one that survives. If you are optimising, the unfolding should be the ones for R-code, not C-code. One other issue is this. TH/GHCi don't currently call the module-initialisation procedure after dynamically linking a module. This is really a bug. The module-init procedure registers foreign exports, so presumably that does not currently work in GHCi. The dynamic linker should really run the init procedures of the (root) modules it loads. Simon

1 0

RE: [Template-haskell] Using a Typ as a Type
by Simon Peyton-Jones 03 Sep '03

03 Sep '03

| > TH doesn't support type splices today; that's one of the things I'm | > actively working on. But I'm not sure if this is what you meant. | | It is but it is very important that: | | 1) We can do dictionary lookups using the spliced type. | | | 2) The lookup happen at compile time so that it can affects the | code being generated. | | 3) Instances declared in the code being compiled (like the DIS | instances above) can be found by this mechanism. That is, | I'm not interested in finding any DIS instances that might have | been present in the source code for ghc. Type splices will behave exactly like expression splices today. I'm not sure whether that fulfils your 1-3 reqts. Perhaps the thing to do is to give a simple but concrete example of what you'd like to do. I couldn't understand the example you gave last time, as I mentioned. Do you think it still says what you mean? Could you give a line by line explanation of what you think should take place? Remember, the execution of TH program can be described by ordinary rewriting rules (replace the LHS of a function by the RHS of the function, suitably instantiated), augmented with the one extra rule $[| e |] = e (Unless you use explicit do-notation.) Simon

2 2

RE: [Template-haskell] Using a Typ as a Type
by Simon Peyton-Jones 03 Sep '03

03 Sep '03

| Is there any way that I can use a Typ (i.e., a reified Type) as a Type inside | a template so that I can use the Typ to select an instance of a type class. | | For example, I'd like to be able to write (this doesn't parse): | | $(test [t[ Float ]] "1.0") | | test :: Q Typ -> String -> Q [Dec] | test qty x = do | ty <- qty | print (read x :: $ty) -- The ':: $ty' part is the important bit | return [] I've Sean's reply and Alastair's reply to that, and I still can't figure out what you are trying to do. The above code looks weird. test is a Q [Dec], but you are doing a print in the middle of it. Why? In principle you can certainly say: $(test [t| Float ]] "2.0") test :: Q Type -> String -> Q [Dec] test qty x = [| read (x::$qty) |] so that $(test [t| Float ]] "2.0") ===> read ("2.0" :: Float) TH doesn't support type splices today; that's one of the things I'm actively working on. But I'm not sure if this is what you meant. Simon

2 1

RE: [Template-haskell] Profiling with Template Haskell
by Simon Marlow 03 Sep '03

03 Sep '03

> | > Then, all you need do is > | > compile C-code without -prof > | > compile R-code with -prof > | > | But we only have one kind of "import", which imports a > module both at > compile-time and run-time. > | You'd be forced to link in the C-code modules in the final program, > and I'm pretty sure something will > | go wrong even if the program doesn't end up referring to > anything from > those modules. > > Ah... you mean the module initialisation tree will still kick > in. Hmm. > But if a module is pure C-code, the mod-init code will still work even > if it's compiled without -prof, wont' it? Admittedly, the c-module > would then a (redundant) part of the runtime executable I realised you'll get a link failure, because the init function contains the build tag, so it's impossible to link non-prof code with prof code (this is a safety feature :-). So, you still need to compile any module which contains compile-time code as both prof and non-prof. The latter will be used at compile time only. There might be some confusion over interface files: GHC will read the profiled interface, so it better be consistent with the non-prof interface, which describes the code we're going to load and run at compile time. One way which is guaranteed to work is to put the compile-time code into a package. Cheers, Simon

1 0

RE: [Template-haskell] Profiling with Template Haskell
by Simon Peyton-Jones 03 Sep '03

03 Sep '03

| > Then, all you need do is | > compile C-code without -prof | > compile R-code with -prof | | But we only have one kind of "import", which imports a module both at compile-time and run-time. | You'd be forced to link in the C-code modules in the final program, and I'm pretty sure something will | go wrong even if the program doesn't end up referring to anything from those modules. Ah... you mean the module initialisation tree will still kick in. Hmm. But if a module is pure C-code, the mod-init code will still work even if it's compiled without -prof, wont' it? Admittedly, the c-module would then a (redundant) part of the runtime executable S

1 0

RE: [Template-haskell] Profiling with Template Haskell
by Simon Marlow 03 Sep '03

03 Sep '03

> Then, all you need do is > compile C-code without -prof > compile R-code with -prof But we only have one kind of "import", which imports a module both at compile-time and run-time. You'd be forced to link in the C-code modules in the final program, and I'm pretty sure something will go wrong even if the program doesn't end up referring to anything from those modules. Cheers, Simon

1 0

RE: [Template-haskell] Profiling with Template Haskell
by Simon Peyton-Jones 03 Sep '03

03 Sep '03

| | Now I know that profiling splicing doesn't make too much sense. That | | is not what I wish to do though. I wish to profile the final | | executable. I've thought more about the question of profiling and TH. The issue is this: how can one compile a program that uses TH so that the resulting executable is profiled I'll call C-code is code that runs at compile time R-code is code that runs at runtime We aren't trying to profile C-code, only R-code. It is possible in TH for a particular function to be both C-code and R-code, but that's unusual. Indeed, if you mix C-code and R-code in a particular module, then the R-code will be linked but not run when TH loads the module; and the C-code will be linked but not run in the final executable. So in practice, I expect that most modules will consist *either* of C-code *or* R-code. Let's assume that's the case. Then, all you need do is compile C-code without -prof compile R-code with -prof And Bob's your uncle. If a module Foo contains both C-code and R-code, then you need to compile it both ways. Make sure that the non -prof way generates Foo.o. For the -prof way, generate Foo.p_o (using -o). TH will look for Foo.o, and that'll be fine. Your final link step must link Foo.p_o. You can't do this with --make. As far as I can see, that closes the issue. Right? If so, would someone (Ian?) like to update the manual to include a section that explains this issue? Many thanks Simon

1 0