Last mail seemed to get lost (think I forgot to CC it to the list): would this work with: $(something [d| f a = a + 1 |]) Such that I can reference the reified type of 'f' from inside 'something'. 'something' would be imported from another file. I am using ghc-6.4 Keean. Sean Seefried wrote:
On 18/02/2005, at 8:11 PM, Keean Schupke wrote:
Is it possible to get at type information from TH? I am thinking of something like the following:
f a = a + 1
{- ghc derives the type: f :: Integral a => a -> a -}
Can I get at this derives type information? It would be very useful for the project I am working on... can I just reify the type of the function?
The answer to this question is a little tricky - it's yes with a few caveats. Firstly, the Q monad can be "run" in two contexts - within the IO monad and with in the TcM monad of the GHC compiler. You can't you `reify' to get type information in the former context. Secondly, you can only reify the type of something that has been imported from another module. No go on the reifying something declared within the module you're reifying in.
I have two pieces of sample code that demonstrate the Q monad being run within the TcM monad and within the IO monad. The first one works, the second doesn't. They are attached.
These built in an old version of GHC 6.3. They should compile and run in GHC 6.5 without *too* much difficulty although I haven't tested it.
Cheers,
Sean
On 19/02/2005, at 2:33 AM, Keean Schupke wrote:
Last mail seemed to get lost (think I forgot to CC it to the list):
would this work with:
$(something [d| f a = a + 1 |])
Such that I can reference the reified type of 'f' from inside 'something'. 'something' would be imported from another file. I am using ghc-6.4
As far as I know you *can't* do this. It is true that TH will type check things that are inside quasi quotes but it will only complete this process if there are no inner splices. There's a good reason for this. TH tries to be as inclusive of meta-programs as it can by not type checking programs at compile-time (unlike, say, MetaML). In fact, unless one heavily restricts the allowable meta-programs type checking them statically is undecidable. So what TH does it wait until all the meta-programming has been done (i.e. all the code has been generated and spliced in) before type checking. The type checking I referred to in the first paragraph seems to be just an extra check to catch some errors earlier. It's not necessary. For a while I was interested in using TH for the transformation of programs. I wasn't interested in generation at all. I started work on a type checking extension to TH that would type check stuff within in quasi-quotes that a) had everything in scope and b) contained no inner splices. However, I never got around to finishing it since I'm doing source-to-source transformation another way now. Cheers, Sean
Ahh, I am doing a form of source to source translation for Haskell. I don't want to maintain the parser for this so TH seemed to be ideal. I would be happy with the restriction of no splices within the meta-quotes. If TH is already type checking (it is, as it will catch type errors in the meta-quoted code) then surely this type info is available, it just needs to be reified? Who maintains that part of the TH code in GHC? Keean Sean Seefried wrote:
On 19/02/2005, at 2:33 AM, Keean Schupke wrote:
Last mail seemed to get lost (think I forgot to CC it to the list):
would this work with:
$(something [d| f a = a + 1 |])
Such that I can reference the reified type of 'f' from inside 'something'. 'something' would be imported from another file. I am using ghc-6.4
As far as I know you *can't* do this. It is true that TH will type check things that are inside quasi quotes but it will only complete this process if there are no inner splices. There's a good reason for this.
TH tries to be as inclusive of meta-programs as it can by not type checking programs at compile-time (unlike, say, MetaML). In fact, unless one heavily restricts the allowable meta-programs type checking them statically is undecidable. So what TH does it wait until all the meta-programming has been done (i.e. all the code has been generated and spliced in) before type checking.
The type checking I referred to in the first paragraph seems to be just an extra check to catch some errors earlier. It's not necessary. For a while I was interested in using TH for the transformation of programs. I wasn't interested in generation at all. I started work on a type checking extension to TH that would type check stuff within in quasi-quotes that a) had everything in scope and b) contained no inner splices.
However, I never got around to finishing it since I'm doing source-to-source transformation another way now.
Cheers,
Sean
On 20/02/2005, at 1:49 AM, Keean Schupke wrote:
Ahh, I am doing a form of source to source translation for Haskell. I don't want to maintain the parser for this so TH seemed to be ideal.
I would be happy with the restriction of no splices within the meta-quotes.
If TH is already type checking (it is, as it will catch type errors in the meta-quoted code) then surely this type info is available, it just needs to be reified?
Check out this code from fptools/ghc/compiler/typecheck/TcSplice.lhs The comment mid-way is quite interesting. tcBracket :: HsBracket Name -> Expected TcType -> TcM (LHsExpr Id) tcBracket brack res_ty = getStage `thenM` \ level -> case bracketOK level of { Nothing -> failWithTc (illegalBracket level) ; Just next_level -> -- Typecheck expr to make sure it is valid, -- but throw away the results. We'll type check -- it again when we actually use it. recordThUse `thenM_` newMutVar [] `thenM` \ pending_splices -> getLIEVar `thenM` \ lie_var -> setStage (Brack next_level pending_splices lie_var) ( getLIE (tc_bracket brack) ) `thenM` \ (meta_ty, lie) -> tcSimplifyBracket lie `thenM_` -- Make the expected type have the right shape zapExpectedTo res_ty meta_ty `thenM_` -- Return the original expression, not the type-decorated one readMutVar pending_splices `thenM` \ pendings -> returnM (noLoc (HsBracketOut brack pendings)) } I found that reifying from another module was almost what I wanted but I wanted to be able to get type information for *all* variables at the very least, and preferably everything. But I remember that I couldn't. I think it might have been the case that you can only get the type of things actually present in .hi files, which I think means just top level functions. Anyone else know about this?
Who maintains that part of the TH code in GHC?
Ian Lynagh would probably have some familiarity with it. As for maintaining it - it's probably Simon Peyton Jones. Cheers, Sean
participants (2)
-
Keean Schupke -
Sean Seefried