- template-haskell - Haskell.org

Splicing in declarations
by Olivier Pernet 24 Dec '08

24 Dec '08

Hi all, I'm trying to generate some function declarations using TH. It seems that there is no way to use splicing inside [d| ... |] quotes... Is this true, and if it is, how do you deal with it? For now I'm only trying to generate function declarations with the given names, and also using the name string in the function body. I'll probably be on to more complex things later - I'm trying to create an embedded DSL for join calculus constructs. Olivier Pernet We are the knights who say echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc

1 0

template-haskell error
by Belka 22 Dec '08

22 Dec '08

Hello! Please, help! I'm a newby to Haskell. While trying to compile HAppS package, I got an error. Should I report it anywhere? I'm going to try to fix it, but how do I localize it? If anybody has apropriate experience, please, share it.. --LOG----------------------------------------- ghc-6.10.1 [~] > darcs get --partial http://happs.org/HAppS/HAppS-Data ... [~] > cd HApps-Data [HApps-Data] > sudo runghc Setup configure --user Configuring HAppS-Data-0.9.3.. [HApps-Data] > sudo runghc Setup build ... [ 7 of 19] Compiling HAppS.Data.HListBase ( src/HAppS/Data/HListBase.hs, dist/build/HAppS/Data/HListBase.o ) Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package packedstring-0.1.0.1 ... linking ... done. Loading package pretty-1.0.1.0 ... linking ... done. ghc: /usr/lib/ghc-6.10.1/template-haskell-2.3.0.0/HStemplate-haskell-2.3.0.0.o: unknown symbol `prettyzm1zi0zi1zi0_TextziPrettyPrintziHughesPJ_lvl77_closure' Loading package template-haskell ... linking ... ghc: unable to load package `template-haskell' -- View this message in context: http://www.nabble.com/template-haskell-error-tp21123496p21123496.html Sent from the Haskell - template-haskell mailing list archive at Nabble.com.

1 1

QuasiQuoting for declarations
by Andrea Vezzosi 03 Dec '08

03 Dec '08

Currently quasiquoting is limited to patterns and expressions, are there any problems in extending it to declarations? we already have [d| ... |] and toplevel splices afterall.

4 3

Fwd: template-haskell depends on packedstring
by Gwern Branwen 01 Dec '08

01 Dec '08

I don't know if you guys have been following this thread, but Duncan reminded I forgot to cc this list; he also comments "How about making a library proposal to change them to abstract newtypes, then we can change the internal representation at will." ---------- Forwarded message ---------- From: Gwern Branwen <gwern0(a)gmail.com> Date: Sun, Nov 23, 2008 at 10:53 PM Subject: template-haskell depends on packedstring To: libraries(a)haskell.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 So I was trying to compile lambdabot with cabal-install. Lambdabot uses Template Haskell for generating some boilerplate, and it was a failed dependency. Template Haskell uses packedstring for... something... and packedstring was a failed dependency: Data/PackedString.hs:83:7: Could not find module `Data.Data': it is a member of package base, which is hidden Now this is a problem, but it's not the problem I am interested in. I am interested in: why is template-haskell using packedstring? Wasn't packedstring obsoleted years ago? I downloaded the TH tarball to see what fascinating things it was using packedstring for, and I found that it's hardly doing anything - it apparently is just encoding module (ModName) and OccName (whatever that is), and then the other functions shift back from PackedString/ModName-OccName to String. (This is all in Language/Haskell/TH/Syntax.hs) I replaced all the PackedString stuff with normal ol' String and compiled fine, and indeed seems to work fine at Template-Haskelly stuff. So here's my suggestions: 1) Remove the packedstring dep and calls from the TH code. It is useless, it shackles the package to a long obsolete one, and so on. Even if we assume that the packedstring code is still faster than native String, and that there's no performance penalty for the conversions back and forth from String to PackedString, and that the possible size increase from linking in PackedString code is not worth worrying about, and we also assume that PackedString is being used on Names large enough to make up for any overhead - even if we assume all that, TH is a compile-time process and so it doesn't matter all that much if we shave a few microseconds off one small part of the compilation process. Installability and cleaner code would be worth that price. 2) If just String is not acceptable, then I understand from dons that the reason we can't use just plain ol' ByteString is because the Names may well be in UTF-8, and ByteString's [Word8]s apparently don't treat that well. Given that, we need some sort of UTF8 bytestring. As it happens, we do in fact have such a thing: Data.ByteString.UTF8 . It looks a bit incomplete, but utf8-string in general is pretty widely-used and reliable (also builds on 6.10): just about every XMonad user uses XMonadContrib which uses utf8-string, and I can count the number of complaints because utf8-string on one hand. Thoughts? I searched thoroughly through various bug-trackers and mailing lists, but this doesn't seem to've come up before. - -- gwern -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREKAAYFAkkqJTsACgkQvpDo5Pfl1oLYoQCgjRSqno+DtyZiLbAS5Pk4l8Ao sqkAn15sBq+alBy5ZVLHIMthjZ6eU6E6 =N8Qj -----END PGP SIGNATURE-----

1 0

RE: [Haskell-cafe] Proposal for associated type synonyms in Template Haskell
by Simon Peyton-Jones 27 Nov '08

27 Nov '08

I've been away. I hope others will reply to this thread too; whatever you decide will end up in TH indefinitely. I know that Roman is interested in this. · You focus just on type families in class declarations (which is indeed where associated types started). But I suggest you also allow them at top level, as GHC does using the syntax type family T a :: * Indeed, since you propose to add to Dec, that'll happen automatically. But perhaps "AssocTySynKindD" is not a good name. Perhaps "TySynFamilyD"? · GHC uses type instance T [a] = Tree a as the way to add an equation to the definition of T. So perhaps "TySynInstance" rather than "AssocTySynD"? · I agree that it'd be good to do data type/newtype families at the same time. Roman needs this. · Your proposal for kinds looks fine. Simon From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of José Pedro Magalhães Sent: 11 November 2008 11:11 To: Haskell Cafe Subject: Re: [Haskell-cafe] Proposal for associated type synonyms in Template Haskell Hello Thomas, I see this is a proposal for a partial implementation of #1673 (http://hackage.haskell.org/trac/ghc/ticket/1673) Maybe it would be good if the remaining syntax (associated datatypes and type families) would also be defined and implemented in TH. Or maybe there isn't much demand for this?... Cheers, Pedro On Wed, Nov 5, 2008 at 15:57, Thomas van Noort <thomas(a)cs.ru.nl<mailto:thomas@cs.ru.nl>> wrote: Hello, Recently, we released a library on Hackage for generic rewriting (package "rewriting" if you are curious). The user of the library is expected to define type class instances to enable rewriting on his or her own datatypes. As these instances follow the datatype declarations closely, we tried to generate the instances using Template Haskell. Unfortunately, associated type synonyms are not yet supported by TH. After a presentation at the WGP'08, Simon encouraged us to write a proposal about adding associated type synonyms to TH, so that it can be added to GHC. So, here is our proposal. The TH AST must allow 1) kind declarations of associated type synonyms in class declarations and 2) their definitions in instance declarations. For example, class Foo a where type Bar a :: * instance Foo Int where type Bar Int = String The TH library defines a datatype Dec which contains a constructor for class declarations and instance declarations: data Dec = ... | ClassD Cxt Name [Name] [FunDep] [Dec] | InstanceD Cxt Type [Dec] ... 1) Associated type synonym kind declarations We suggest to add a constructor to the Dec type: ... | AssocTySynKindD Name [Name] (Maybe Kind) ... assocTySynKindD :: Name -> [Name] -> Maybe KindQ -> DecQ The first field is the name of the associated type synonym, the second field is a list of type variables, and the third field is an optional kind. Since kinds are not yet defined in TH, we have to add some kind of kind definition (pun intended): data Kind = StarK | ArrowK Kind Kind type KindQ = Q Kind starK :: KindQ arrowK :: KindQ -> KindQ -> KindQ We explicitly choose not to reuse the Type type to define kinds (i.e., type Kind = Type as in GHC) since we think a separation between the two worlds is much clearer to the users of TH. 2) Associated type synonym definitions We suggest to add another constructor to the Dec type: ... | AssocTySynD Name [Type] Type ... assocTySynD :: Name -> [TypeQ] -> TypeQ -> DecQ The first field is the name of the type synonym, the second field is a list of type arguments, and the third field is the body of the type synonym. We would like to hear your comments to this proposal. Regards, Thomas _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org<mailto:Haskell-Cafe@haskell.org> http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Creating a invalid declaration in TH
by Sean Leather 14 Oct '08

14 Oct '08

Apparently, I can create a function declaration (FunD) with a string containing an invalid sequence of characters. It passes typechecking and compiles. It even shows up in GHCi! The function name is "ep:#:", and the :#: is derived from an infix type constructor. In GHCi (6.8.3), I type "ep", hit <Tab> to get the list of completions, and, sure enough, there it is! When I try to use it, GHCi interprets it as two distinct symbols as it should. Template Haskell's claim to fame is that it allows you to do "type-safe compile-time meta-programming," and while this issue is perhaps considered lexical rather than type-level, I'm wondering if there should be some additional error checking (somewhere) to account for this. I admit, I wouldn't know how to do this given the TH API, since Name is used for functions, infix operators, and everything else. Regards, Sean

1 0

Examples?
by Magnus Therning 21 Sep '08

21 Sep '08

I've just started looking into TH to remove some of the tedious work of writing access functions for a few datatypes. However I've found precious few examples of "getting into" datatypes. Basically I want to get to 'dInt' and 'dString' in the datatype below: data Data = Data { dInt :: Int, dString :: String } /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe

2 5

using [d| class or fun |] and only substituting names?
by Marc Weber 03 Sep '08

03 Sep '08

Is there a way to write something like this? -- packages: template-haskell -- ghc-options: -fth module Main where import Language.Haskell.TH import Control.Monad main = do putStrLn . show =<< runQ [d| class $(mkName "abc") m elc stc3 elc3 st2 el2 st3 el3 -- line 9 | st2 stc3 -> st3, el2 elc3 -> el3 where $(mkName "foo") :: m Int elc Int elc stc3 elc3 a -> m st el st2 el2 st3 el3 a |] |9 col 12| parse error on input `$(' Marc Weber

3 3

"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