- template-haskell - Haskell.org

RE: [Template-haskell] How to extract name and type of exported functions in modules
by Simon Peyton-Jones 21 Oct '09

21 Oct '09

| -- If it exports any prelude indentifiers (not only the Prelude itself, | but also for example Data.List), I have no idea how to get at | their types --- lookupGlobalName does not find them. Well, it claims that it should find them. Would you like to make a reproducible test case and file a Trac bug report? | -- I cannot find any re-exported instances. The ``package InstEnv'' | obtained from tcGetInstEnvs after loading a library module interface | (via findAndReadIface) seems to contain only the module's own exported | instances, which are the same instances I also find via mi_insts. | (For source modules, where I use typeCheckModule, | I've only been able to find the module's own exported instances via | hptInstances). Hmm. GHC does not read every interface file for every module in every package that is transitively visible from the current module. Instead it relies on the fact that before an instance (C T) is useful, you must have a hold of Class C and TyCon T. So you'll have loaded *their* interfaces, and thereby loaded their instances. (Except for orphan instances, which *are* loaded eagerly.) I can see that this is inconvenient; on the other hand, do you really want ALL the instances of Ord, say? Perhaps there should be an interface for load instances that relate to the following Names Indeed, there is: LoadIface.loadInterfaceForName. Does that help? What's the desired behaviour? I really wish there was someone who took ownership for the GHC API, as seen by "customers" of the API. At the moment it grows incrementally, without proper design. Maybe no one feels able to, because they think GHC HQ will do it, but (a) we are too busy and (b) we represent the suppliers of the API, not the customers. Any volunteeers? Simon

1 0

RE: patch applied (ghc): Three improvements to Template Haskell (fixes #3467)
by Simon Peyton-Jones 11 Sep '09

11 Sep '09

| > Declaration-level splices with no "$" | > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | > This change simply allows you to omit the "$(...)" wrapper for | > declaration-level TH splices. An expression all by itself is | > not legal, so we now treat it as a TH splice. Thus you can now | > say | > data T = T1 | T2 | > deriveMyStuff ''T | | Nice. | | There has been talk int the cast about allowing things like | class T, type T | etc in the module export list. Perhaps you should also be able to say | | data T = T1 | T2 | deriveMyStuff (type T) | | rather than using the somewhat odd '' syntax. Interesting idea. You're making use of the *keyword* 'type', although it's unexpected in an expression context. Trouble is, we lack a keyword for 'value'! I suppose we could invent one. Thus module Foo( type T(..), class C, value f, value g ) and deriveMyStuff [type T, value f] I wonder if that would have merit? What do other TH afficionados think? Simon

1 0

How to use Template Haskell build Map ?
by Andy Stewart 08 Sep '09

08 Sep '09

Hi all, I have below instances: instance PageViewState DiredViewState where instance PageViewState StringViewState where I can use Language.Haskell.Exts.Parser scan above instances got list: typeList :: [Type] typeList = [TyCon (UnQual (Ident "DiredViewState")),TyCon (UnQual (Ident "StringViewState"))] So question is how to use Template Haskell and above `typeList` build below `Map` at compile-time? tagmap = M.fromList [(typeIdOf StringViewState, Exists (Dict :: PageViewStateDict StringViewState)) ,(typeIdOf DiredViewState, Exists (Dict :: PageViewStateDict DiredViewState))] Thanks! -- Andy

1 0

ANN: New release of ZeroTH
by Robin Green 23 Jun '09

23 Jun '09

This announcement will only be of interest to Haskell programmers using, or thinking of using, Template Haskell. I am very pleased to announce a new release (2009.6.23.3) of ZeroTH (also known as zeroth), a tool for preprocessing Haskell code to run splices and remove Template Haskell dependencies: http://hackage.haskell.org/package/zeroth For example, you could use it to reduce the size of your Haskell program binaries, if you use Template Haskell. (zeroth now actually uses itself on itself, for this very purpose, and you can use the Distribution.ZeroTH module for that in your own cabal projects.) It's still very much a hack - in that it would probably be more efficient and clean to implement it as an option to GHC - but hopefully now at least it's a slightly *better* hack. Lemmih has kindly agreed to hand over the job of being maintainer of ZeroTH to me. So please send any patches or complaints my way. The new darcs repository for the project, which is a darcs 2 repository, is at: http://patch-tag.com/publicrepos/zerothDarcs2 For this release, the "cabal" command-line tool is the only officially supported means of installation. So you should do something like: cabal update cabal install zeroth to install it. To get a summary of command-line options, type: zeroth --help Major changes from previous releases: * Much more Haskell code is now supported. This is partly because the code has been updated to work with the just-released haskell-src-exts 1.0.0; and partly because it supports a wider variety of Template Haskell code, including code which refers to definitions declared in the same source file. * It is now compulsory to specify any Haskell language extensions you are using in the input file, with a LANGUAGE pragma. (For debugging purposes, zeroth prints to stderr the result of parsing the LANGUAGE pragma, if any. If haskell-src-exts doesn't understand the LANGUAGE pragma, this will be Nothing. But that shouldn't happen.) * Template Haskell imports are now *automatically* stripped by default by zeroth, and so cpphs doesn't need to be run if you aren't otherwise using CPP. * New command-line options have been added (see zeroth --help). * Error messages are now more informative. * Librification! Almost anything can benefit from being made into a library, and zeroth is no exception. Of course, the executable is still there. * You can still use it on certain code which doesn't compile in GHC (yes, really, I've tested this!) but you now have to use the --only-splices option if you want to do this. Obviously, the splices themselves have to compile. --only-splices also makes zeroth faster. It is very lightly tested, so it might not work for your code out of the box. Please let me know if you have any problems with it, no matter how small. Happy hacking, -- Robin

1 0

New TH features in the HEAD
by Manuel M T Chakravarty 26 Mar '09

26 Mar '09

I added some new language features to Template Haskell in the HEAD repository: * type families, including associated types, * kind annotations, * INLINE and SPECIALISE pragmas, and * bang patterns. Especially, type families were repeatedly requested <http://hackage.haskell.org/trac/ghc/ticket/1673 >. Please give these extensions a spin and let me know of any problems that you may encounter. Unfortunately, I had to change the Language.Haskell.TH API in a way that is not backwards compatible due to the necessary extensions in the Language.Haskell.TH.Syntax. For the moment, this will only affect users of the development version, but I expect these changes to be in the next stable release, 6.12, too. Happy Hacking! Manuel

1 0

generation of type signatures for Accessors
by brian＠lorf.org 25 Mar '09

25 Mar '09

Hey, I'm trying to modify data-accessor-template 'deriveAccessors' to generate type signatures so -Wall doesn't complain. > data P = P { x_::Int, y_::String } > $(deriveAccessors ''P) should generate > x :: Accessor P Int > ... > y :: Accessor P String > ... That seems pretty easy. But > data P a = P { x_::a, y_::a } > $(deriveAccessors ''P) should generate > x :: forall a. T (P a) a > ... > y :: forall a. T (P a) a > ... I was able to write TH to generate code for the first situation, but it failed for the second, and I don't feel confident about writing TH that will work generally. How difficult is it?

2 4

Re: [Haskell-cafe] Proposal for associated type synonyms in Template Haskell
by Sean Leather 19 Mar '09

19 Mar '09

It looks like Manuel Chakravarty is making some progress on this. http://hackage.haskell.org/trac/ghc/ticket/1673#comment:11 Sean On Thu, Jan 15, 2009 at 21:57, Nicolas Frisby wrote: > Any movement on this? > > (I am actually just looking forward to generating kind ascriptions and > having access to the kinds when processing TH.Dec, TH.Type, and such.) > > 2008/11/27 Simon Peyton-Jones <simonpj(a)microsoft.com>: > > 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> 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 >

1 0

kinds in TH
by Nicolas Frisby 19 Jan '09

19 Jan '09

I've not found any previous discussions of this effort. I am unaware of any identified obstacles. Here's my idea so far. Disclaimer: this is my first foray into GHC internals; I'd appreciate criticism before I wander into implementation. 1) add 'data Kind = Star | ToK' to Language.Haskell.TH.Syntax 2) add a field of type Kind to the Language.Haskell.TH.Info type's TyConI, PrimTyConI, and TyVarI constructors. 3) adjust GHC's TcSplice.reifyTyCon function to provide these Kinds (From what I can tell, the TyCon.tyConKind :: TyCon -> Kind and Var.tyVarKind :: TyVar -> Kind functions pretty much provide what we'd need. TcSlice.reifyName would need to change a bit, because the TyVars' kind information is currently hidden behind the NamedThing class.) That's as far as I've thought it through. It would provide kind information to the TH user, but not the ability to generate kind signatures. To do so, it seems, would require adding the kind information to the TH.Dec and TH.Type types instead of TH.Info (since GHC's Convert module doesn't use TH.Info for generating HsSyn). Thus, the alternative: 2') wherever [Name] occurs for a list of type variables, replace it with [(Name, Kind)] (within within TH.Dec(DataD, NewtypeD, TySynD, ClassD), TH.Con(ForallC), and TH.Type(ForallT)) Though this would burden the user with providing kind signatures for all type variables - I suppose a sum type could be used instead of the draconian pair. (The results of reify would always include the kind (if it isn't star?).) Backwards compatibility seems a lost cause, but the difference could amount to little more than injection and projection with respect to the TH datatypes for type variables. How's it sound? Any pertinent wisdom out there?

1 0

Finding instances for a data type
by Martin Hofmann 15 Jan '09

15 Jan '09

I am also interested in such a feature of TH. It is not one of my burning issues, but reading this post I thought one could pool together. > I'd like to use TH to find what classes a type is an instance of, or > alternatively all known instances of a class. In particular I am additionally interested in accessing the class functions via an instance of that particular class. > As far as I can tell this is not yet possible. This confirms my conjecture, too. > How hard would it be to implement? I'd like to help out, > but it would be nice to have some idea of where to start. Any tips? Unfortunately, I don't have a clue either. Greetings, Martin

3 2

Finding instances for a data type
by hellfeuer 14 Jan '09

14 Jan '09

I'd like to use TH to find what classes a type is an instance of, or alternatively all known instances of a class. As far as I can tell this is not yet possible. How hard would it be to implement? I'd like to help out, but it would be nice to have some idea of where to start. Any tips? Thanks Salil

1 0