July 2008 - template-haskell

"contexts differ in length" fires when using splices in non-recursive bindings?
by Claus Reinke 18 Jul '08

18 Jul '08

My TH is a bit rusty, so I'm probably doing something wrong here: {-# LANGUAGE TemplateHaskell #-} module TH where import Language.Haskell.TH monad qe = qe >>= return . AppE (VarE 'return) The symptom appears in the following module, when I replace the native 'return's with the spliced ones: {-# LANGUAGE TemplateHaskell #-} import TH y :: Monad m => a -> m a y a = return a -- $(monad [| a |]) x :: (Monad m,Eq a) => m a x = return undefined -- $(monad [| undefined |]) There is no recursion, at least no intended one, but where the native version compiles just fine, the spliced version yields: THtest.hs:10:0: Contexts differ in length (Use -XRelaxedPolyRec to allow this) When matching the contexts of the signatures for y :: forall (m :: * -> *) a. (Monad m) => a -> m a x :: forall (m :: * -> *) a. (Monad m, Eq a) => m a The signature contexts in a mutually recursive group should all be identical When generalising the type(s) for y, x Failed, modules loaded: TH. Could someone please tell me what is causing this? In the real code, the errors are even more confusing. Try removing the type signatures, for instance, or just remove the 'Eq a' constraint, then try evaluating '[y (),x]' in GHCi. Claus

4 4

FW: [GHC] #2340: Improve Template Haskell error recovery
by Simon Peyton-Jones 09 Jul '08

09 Jul '08

Dear Template Haskell folk Do you want us to execute this proposal for GHC 6.10? http://hackage.haskell.org/trac/ghc/ticket/2340 No replies => no action. Simon

1 0

splicing types
by Robert Greayer 02 Jul '08

02 Jul '08

Hi, I've been using TH to implement a library that generates code in a 'foreign' language that corresponds to a haskell ADT, as well as the haskell & foreign code required to transmit (i.e. serialize and deserialize) values back and forth between a haskell program and the foreign program. I've run into some situations in which it would be useful for there to be a way to control the code generation declaratively by providing additional meta-data to the code generator, beyond just the ADT(s) themselves. For example, suppose in a group of ADTs, certain fields should be omitted when serialized, and therefore not represented in the 'foreign' types, e.g.: > data Bar { > val1 :: String, > val2 :: Int -- omit this in serialization > } As a 'first order' stab at handling this issue, I thought of using type aliases, e.g > type Omitted a = a ... > val2 :: Omitted Int which could be generalized to a sort of 'annotation type', e.g. > type Ann a b = a > type Omitted = () -- a particular annotation ... > val2 :: Ann Int Omitted you could have multiple annotations, e.g. > val2 :: Ann Int (Omitted,Ann1,Ann2) -- an Int with three annotations The code generator 'sees' the aliases, and can therefore act on the ones it understands. This works, but I immediately run into situations where more flexibility is needed. Indeed, in the example I've chose ('omit'), all works ok when serializing the data, but what about *de* serializing (in haskell)? Some value needs to be chosen for the omitted field. An arbitrary default of (say) zero may not be appropriate. What I'd really like to be able to do is parameterize my annotations with values. 'Omitted' would be parameterized with the default value to use, e.g. > type Omitted a = () ... > val2 :: Ann Int (Omitted 1000) But of course this doesn't work, as I'm dealing with types here, not expressions. I could do something extremely hokey (hokier even than this system of annotations), like: > type I1000 = () ... > val2 :: Ann Int (Omitted I1000) -- read as 'omitted, with default of 1000' The code generator would determine the default value based on the name of the type 'Omitted' is applied to. The user of the annotation system would have the ugly task of creating 'dummy' type aliases for any values that need passing (and it would be quite cumbersome to attempt a naming convention for strings, etc.) It's at this point that I had the (for me) clever idea of simply writing a 'type level encoder' for any haskell expression, and then splicing in the encoding at the appropriate point, e.g. my integer as a tuple-type of binary digits: (One,Zero,Zero,One) would be a type encoding of '9', given the existence of type (aliases) such as: > type One = () > type Zero = () A function to encode an integer into the TH.Syntax representation of such a tuple -- (AppT (AppT (AppT (AppT (TupleT 4) (ConT ''One)) (ConT ''Zero)) (ConT ''Zero)) (ConT ''One)) is fairly trivial, as is a function to decode it back into an integer. It should (I think) be possible to write a pair of functions: > encT :: Q Exp -> Q Type > decT :: Q Type -> Q Exp to encode/decode arbitrary expressions into/from types. which would then allow my annotations to look like: > val2 :: Ann Int (Omitted $(encT [|1000|])) and allow me to annotate types with just about anything else, as well, with the ugly details of encoding/decoding hidden from both the user of the annotation system, and any code generation system that makes use of annotations. Which I found quite pleasing, since this 'quasi-annotations' feature is probably more powerful than some similar, 'intentional' annotation features of other languages, despite (afaik) not being an envisaged use of the language features involved. But then I tried it out and found that I'm trying to splice into what is currently an invalid splice position for TH. (Indeed, on the very day that I decided to try my idea out concretely, the relevant ticket affecting type declarations as valid splice positions was downgraded to low priority, and disincluded from GHC 6.10 -- http://hackage.haskell.org/trac/ghc/ticket/1476) So I was wondering if 1) splicing types is inseparable from the (harder?) problem of splicing patterns and 2) if splicing types is something that will is likely at some point to be implemented (is it that a good solution isn't yet apparent, or that it's just not important enough for the goals of TH?) and 3) has this idea, or something similar, been explored (regardless of the fact that it won't work with TH as-implemented) before? Thanks, rcg

5 7