RE: [Template-haskell] RE: Template Haskell...
Not so. We split at top-level declaration splices. What about this, though? NO splitting involved. f :: Int -> Q Exp f n = [| n+2 |] g x = x + $(f 3) Furthermore, we don't want to *always* compile-to-byte-code all the preceding code in a module. usually none of it'll b needed S | -----Original Message----- | From: template-haskell-bounces@haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Alastair Reid | Sent: 31 October 2003 17:35 | To: Simon Peyton-Jones; MR K P SCHUPKE; template-haskell@haskell.org | Subject: Re: [Template-haskell] RE: Template Haskell... | | On Friday 31 October 2003 5:24 pm, Simon Peyton-Jones wrote: | > Trouble is, that's thoroughly awkward one to implement, because it means | > compiling the transitive closure of all the things in this module | > referred to by the bit you are running. I'm sure it's doable, but I'm | > not looking fwd to it. | | I can see that compiling a module one set of declaration groups at a time | won't be much fun but given the way you split modules into lists of | declaration groups separated by top-level splices, it seems easy enough to | know what to compile: | | You have to compile all the code above the current top-level | splice or declaration group. | | -- | Alastair Reid | | | | _______________________________________________ | template-haskell mailing list | template-haskell@haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell
On Friday 31 October 2003 5:45 pm, Simon Peyton-Jones wrote:
Not so. We split at top-level declaration splices. What about this, though? NO splitting involved.
f :: Int -> Q Exp f n = [| n+2 |]
g x = x + $(f 3)
The standard dependency analysis done for typechecking will have already found a reasonable approximation of the transitive closure of templates needed by g. But, more importantly, tell me again why you need to find those dependencies first anyway? Would the problem not go away if you byte-code-compiled f lazily?
Furthermore, we don't want to *always* compile-to-byte-code all the preceding code in a module. usually none of it'll b needed
Would lazy compilation help? You'd have to build a bunch of thunks which, if evaluated, would yield byte-code objects but you wouldn't have to actually compile the code. -- Alastair Reid
participants (2)
-
Alastair Reid -
Simon Peyton-Jones