- template-haskell - Haskell.org

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

RE: [Template-haskell] Language.Haskell.THSyntax data types deriving Eq
by Simon Peyton-Jones 22 Aug '03

22 Aug '03

I rather agree with Ian on this point. Ian, if you want to go ahead and implement your suggestion, that's fine with me. Incidentally, I've been quiet on the TH front because (a) I've been on holiday, (b) I'm deeply immersed in a reworking of the typecheck/renamer which should make it much easier to implement type splices (as well as being generally more wonderful). Now it's time for ICFP, then catching up, then I'll be back in business. Meanwhile, it'd be useful if any of you who are actively using TH would identify your top priorities for changes/fixes/improvements. If there is a consensus on what's important, I'm much more likely to do something about it! You can post your priority list to this mailing list. Even better if accompanied with volunteering to help do it. Simon | -----Original Message----- | From: template-haskell-admin(a)haskell.org [mailto:template-haskell-admin@haskell.org] On Behalf Of | Ian Lynagh | Sent: 13 August 2003 02:08 | To: template-haskell(a)haskell.org | Subject: Re: [Template-haskell] Language.Haskell.THSyntax data types deriving Eq | | On Wed, Aug 13, 2003 at 10:37:05AM +1000, Sean Seefried wrote: | > On Wed, 13 Aug 2003, Ian Lynagh wrote: | > | > > This opens up the issue of how much difference should be allowed in | > > things before they stop being equal, e.g. should "Let ds1 in e" and | > > "Let ds2 in e" be equal if they have the same statements in a different | > > order? What about alpha renaming of variables in expressions? It doesn't | > > take many acceptable differences before it starts to get rather | > > complicated, not to mention confusing to the user when some differences | > > are accepted but others aren't. | > > | > > I think the best choice is that two datastructures are equal (==) iff | > > they are identical. | > | > That's certainly the simplest solution but I'm not convinced it's the | > best. Couldn't you simply write a "canonical-ise" function which takes an | > expression and puts it into some sort of canonical form and then tests for | > equality. However, there are many issues to consider like you said. | > Eta-reduction would another to think about. | | Ultimately you hit the undecidability of the equivalence of Haskell | expressions. The principle of least surprise suggests to me going for | the other extreme rather than trying to find the best spot in the | middle. | | This is useful for "Has this changed after I applied a function to it?" | but not "Are these definitely the same?" which I think are the two | generally useful functions. It's also the easier to implement and the | more efficient of the two. | | | Thanks | Ian | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

(no subject)
by Sean Seefried 13 Aug '03

13 Aug '03

Hi Alastair, > 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 think the following should do the job -------- {- TypeSplices.hs -} module TypeSplices where import Language.Haskell.THSyntax rtype :: TypeQ rtype = return (ConT "Float") test :: TypeQ -> ExpQ test rtype = lamE [varP "x"] (sigE (appE (varE "read") (varE "x")) rtype) ----------- {- Main.hs -} module Main where import TypeSplices import Language.Haskell.THSyntax main :: IO () main = putStrLn (show ($(test rtype) "123.45")) ---------- This compiles under ghc-6.1 and will require a few subtle changes for ghc-6.0. It correctly reads "123.45" as a float. Interestingly, declaring test as: test rtype = [| \x -> read x :: $(rtype) |] does not work as we get a parse error on "$(". Something to get fixed? Note that you cannot pass the reified type (rtype) as an argument at run-time, and you must declare rtype in TypeSplices.hs. This may not be what you wanted of course, but this is outside the scope of what Template Haskell is capable of. Sean

2 1

Language.Haskell.THSyntax data types deriving Eq
by Andre Pang 13 Aug '03

13 Aug '03

Is there a reason why any/all of the data types in Language.Haskell.THSyntax (such as Dec, Stmt, and Type) don't derive Eq? I'm thinking that it would be useful for test suites, in particular. -- % Andre Pang : trust.in.love.to.save

4 4

Using a Typ as a Type
by Alastair Reid 07 Aug '03

07 Aug '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 been going back and forth on whether or not this fits the existing TH framework or represents a major excursion into multi-stage templates. I'd be willing to implement this feature if it fits the existing TH framework (i.e., it doesn't require a complete reimplementation of TH). -- Alastair Reid

1 0

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

07 Aug '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. Hmm, yes good point. GHC compiles different binaries for profiled and non-profiled execution. Splice code that runs at compile time should presumably be non-profiled (though I'm sure someone will want to profile it too). So TH should link non-profiled libraries at compile time, but it's not clever enough to realise this. I'll put this on my list of things to fix. I'm in the middle of a heart transplant on GHC at the moment, aimed at making a better substrate for TH, so I may not fix this very quickly unless it's important to you. It will mean that you'll have to compile your own program modules both profiled and non-profiled -- the former for run-time and the latter for compile time -- unless you keep compile-time code and run-time code in separate modules. That's annoying but I don't see an easy alternative. Simon

2 1

RE: [Template-haskell] reifyDecl problem
by Sean Seefried 29 Jul '03

29 Jul '03

On Sun, 27 Jul 2003, Tim Sheard wrote: > At 08:22 AM 7/23/2003 +1000, you wrote: > >So correct me if I am wrong. Quasi-quoatation is not reification because > >quasi-quoted code is not a data structure, it is simply another form of > >expression. > > Quasi quoted code is sort of special. It is both a data structure > and a delayed expression. When I talk of reification, I mean a way > to turn a value into a quoted piece of code. > > reify (pred . succ) ---> [| \ x -> x |] > > This is not possible in MetaML. Can one do case analysis on the structure of quasi-quoted code however? Sean

1 0

RE: [Template-haskell] reifyDecl problem
by Simon Peyton-Jones 22 Jul '03

22 Jul '03

| > But Section 8.1 of "Template Meta-programming for Haskell" says: | > | > "In a similar way, reifyDecl f, gives a data structure | > that represens the value declaration for f;..." | > | > and later "... useful to restrict the use of reifyDecl to type | > constructors, classes, or variables (e.g. functions) declared at the | > top level..." | > | > From that I made a conclusion that it is possible to reify function | > declarations (the most interesting ability of TH to me comparing with | > C++, for instance). And I still hope :) that it is possible and the | > error message above is just due to mere bug. | | This you definitely can't do and oh, how I wish you could. The closest | you can get is to define a function as reified code and then splice it. | Example: | | d_fun = [d| fun = <function body> |] You can certainly consider it a missing feature, if not exactly a bug (though the error message is horrible). I think you'll always be restricted to functions defined in the same module. For example import Prelude foo = $(do_it (reifyDecl map)) won't work, because 'map' isn't defined in this module. To make this work, I'd need to store the original source code for every function in each module's interface file, just in case someone later imported and reified it. But it seems a bit unpleasant for module boundaries to be significant in this way. I'm not sure what to do about this. I'd be interested to know whether the same-module restriction would defeat the purposes for the "oh, how I wish I could" applications. simon Simon

2 1