- template-haskell - Haskell.org

RE: Representing unboxed tuples in TH
by Simon Peyton-Jones 26 Nov '03

26 Nov '03

Only that the more one adds to THSyntax the more any program running over it needs to deal with. Functional dependencies? scoped type variables? etc S | -----Original Message----- | From: Sean Seefried [mailto:sseefried@cse.unsw.edu.au] | Sent: 26 November 2003 09:56 | To: template-haskell(a)haskell.org | Cc: Simon Peyton-Jones | Subject: Representing unboxed tuples in TH | | I've noticed that you can't represent unboxed tuples in Template | Haskell. Is there any strong reason for why this would be hard to do? | My knowledge on this topic is scant. | | Sean |

1 0

Representing unboxed tuples in TH
by Sean Seefried 26 Nov '03

26 Nov '03

I've noticed that you can't represent unboxed tuples in Template Haskell. Is there any strong reason for why this would be hard to do? My knowledge on this topic is scant. Sean

1 0

RE: [Template-haskell] TH Module names
by Simon Peyton-Jones 21 Nov '03

21 Nov '03

Yes, in the HEAD it's already spit into Language.Haskell.TH Language.Haskell.TH.THSyntax Language.Haskell.TH.THLib Perhaps I should change "THSyntax" to "Syntax" and similarly for Lib. Seems like a good plan. At the moment, Lib contains the pretty printer, but maybe I should split that off too. Does anyone else have opinions about this? Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Tomasz Zielonka | Sent: 20 November 2003 23:28 | To: template-haskell(a)haskell.org | Subject: [Template-haskell] TH Module names | | Hello! | | How about renaming | Language.Haskell.THSyntax | to | Language.Haskell.TH.Syntax | | Then we could split this module into smaller ones, like: | | Language.Haskell.TH.Syntax | Language.Haskell.TH.Pretty | Language.Haskell.TH.UsefulHelperFunction (or something shorter) | ... | | I think it is nicer and would be helpful when experimenting in GHCi. | With the current big module when I do | :browse Language.Haskell.THSyntax | I get 7 screens of declarations (would be 9 screens on 25 line | terminal). | | Of course you can keep the old module and reimport the new modules from | it. | | Best regards, | Tom | | PS. TH saved me a big amount of tedious, bug-prone work. Thanks! :) | | -- | .signature: Too many levels of symbolic links | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0

TH Module names
by Tomasz Zielonka 20 Nov '03

20 Nov '03

Hello! How about renaming Language.Haskell.THSyntax to Language.Haskell.TH.Syntax Then we could split this module into smaller ones, like: Language.Haskell.TH.Syntax Language.Haskell.TH.Pretty Language.Haskell.TH.UsefulHelperFunction (or something shorter) ... I think it is nicer and would be helpful when experimenting in GHCi. With the current big module when I do :browse Language.Haskell.THSyntax I get 7 screens of declarations (would be 9 screens on 25 line terminal). Of course you can keep the old module and reimport the new modules from it. Best regards, Tom PS. TH saved me a big amount of tedious, bug-prone work. Thanks! :) -- .signature: Too many levels of symbolic links

1 0

RE: Aggressive inlining
by Simon Peyton-Jones 20 Nov '03

20 Nov '03

Sounds as if you might need Template Haskell http://research.microsoft.com/~simonpj/papers/meta-haskell/ Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Blue | Steel | Sent: 19 November 2003 22:43 | To: haskell-cafe(a)haskell.org | Subject: Aggressive inlining | | I'm working on a parlor trick. | | I would like to solve a 3-SAT problem at compile time, | so that the executable is super fast. | | Consider | --------------------------------------------------- | formula (x1,x2,x3) = (x1 || x2) && x3 | | tf = [True, False] | | assignments = [(x1,x2,x3)|x1<-tf,x2<-tf,x3<-tf] | | solutions = filter formula assignments | | main = do print solutions | --------------------------------------------------- | | Theoretically, a compiler could optimize this to | --------------------------------------------------- | main = do print [(True,True,True),...] | --------------------------------------------------- | | Is this actually possible in GHC? I've played with | inline pragmas and looked at -ddump-..., but I haven't | made much progress. | | Of course, the goal is to replace "formula" with a | formula that takes a 30-tuple instead of a triple and | really let GHC crank. | | Thanks for any help. | | | __________________________________ | Do you Yahoo!? | Protect your identity with Yahoo! Mail AddressGuard | http://antispam.yahoo.com/whatsnewfree | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: Reification in TH
by Simon Peyton-Jones 19 Nov '03

19 Nov '03

| I've played around with reifying types and found that one can only | reify names that have the following format: | | Name occ (NameG th_ns mod) Well that's just a bug. It's supposed to be possible to do f x = $(do { ... reify 'x .... }) modulo the caveats about how much of x's type will be visible by then. I'll fix that shortly. Meanwhile you want something more ambitious that I don't understand yet. | I might have a block of declarations like this | | ds = [d| f = .... | g x = f .... x.... | |] | | It would be extra nice if I could reify the type of "x" in the | following code. What do you mean by "in the following code"? You can't mean ds = [d| f = .... g x = f .... x.... |] w = do { reify 'x ... because x isn't in scope there. And even if you say w = do { reify (mkName "x")... } you'll get a dynamic error because x isn't in scope. So I really don't know what you mean. Perhaps what you mean is: let the Exp data structure be able to represent type-annotated terms when [| ... |] constructs a data structure, let it be replete with type annotations provide a way to look at these type annotations when taking the data structure apart I have thought about this a bit in the past, and it's tricky. An obvious place to attach type annotations would be to put the Type of a Name inside the Name. So you can say nameType :: Name -> Type to get the type of a variable. (Presumably it'd fail if given the Name of a type constructor or class.) But when the programmer constructs a Name with newName or mkName, he doesn't want to supply a type. So sometimes an Exp will have type-annotated Names and sometimes not. And there's still the ever present aspect of only having *partial* type information. (More tiresomely, GHC adds lots of crud -- dictionary applications and abstractions etc -- to the typechecked term, so it's not entirely easy to get back to the original term. But that part must be soluble.) Simon Of course the problem is that we don't even know if | "f" (or "g" for that matter) is going to type check until we've spliced | it. So we can only reify "x"'s type at splice time. | | I need the ability to reify "x"'s type and then, based on the | information I get back, transform the block of declarations, "ds", in a | certain manner. | So I would in effect be doing a kind of "speculative splice". But a | splice of top-level declarations can only occur at the top level! What | I'm suggesting would be a speculative splice inside the body of a | function, something that will ONLY work when the DecQ that we are | splicing only contains Names that refer to functions in other modules | or within the DecQ. (That is, we can't have the functions referring to | variables outside the DecQ but in the current module!). Fortunately, | this condition is satisfied by the DecQs I wish to do reification in. | | I can understand why no one would want to write a "reify" function as | described above. | | But the only reason I've been throwing functions in [d| |] brackets is | because I can't reify entire modules. (We would have to bloat .hi files | for this to be the case.) But, say this were possible. Then it would | be MUCH easier to code a reify function that could return the types of | local Names, because we would already known that the module which we | are reifying type checks and then in the bloated .hi files we could | simple annotate each occurrence of a Name with its type. This would be | extremely useful to me. | | Cheers, | | Sean |

1 0

PS to Names
by Simon Peyton-Jones 19 Nov '03

19 Nov '03

PS: the proposal of my previous message would also fix this (taken from the data decl of Exp) | InfixE (Maybe Exp) Exp (Maybe Exp) -- {x + y} or {(x+)} or {(+ x)} or {(+)} -- It's a bit gruesome to use an Exp as the -- operator, but how else can we distinguish -- constructors from non-constructors? -- Maybe there should be a var-or-con type? -- Or maybe we should leave it to the String itself? Now the operator can be just a Name. I'm even keener. Simon

1 0

Namespaces
by Simon Peyton-Jones 19 Nov '03

19 Nov '03

Template Haskellers Consider this reify (mkName "T") Do we get the data constructor T or the type constructor T? For in-scope top-level things we can say reify 'T reify ''T to distinguish, but currently there's no way to distinguish for dynamically scoped names built with mkName. Clearly a global Name, one made by 'T or ''T, keeps track of its own name space. An obvious possibility would be to make all Names do so. So then one would have mkVName :: String -> Name -- variables and data constructors mkTName :: String -> Name -- types, classes, and type variables Dually, one could have name-space predicates isVarName, isDcName, isTcName, isTvName :: Name -> Bool which said if a Name described a variable, datacon, tycoon, tyvar repectively. (mkVName would use the capitalisation convention to decide whether the Name was a datacon or a variable; similarly mkTName.) One advantage of this is that we could get rid of the VarE/ConE distinction, and the VarT/ConT distinction, which would be quite worthwhile, I think. And it would fix the problem I started this message with. But it would mean that the (hopefully few) mkName calls would need to change to mkVName and mkTName. I'm inclined to do this. Any comments? Simon

1 0

Reification in TH
by Sean Seefried 19 Nov '03

19 Nov '03

Hi Simon and fellow TH users, > Have the TH s you mentioned in your communities report now been fixed? I've played around with reifying types and found that one can only reify names that have the following format: Name occ (NameG th_ns mod) which means that it's not possible to reify the Name "x" in the following expression: \x -> x + 3 since it is local. I realise that implementing such reification is a whole new can of worms. I'll give you an idea of what I want and then you can tell me whether it's infeasible or not. I might have a block of declarations like this ds = [d| f = .... g x = f .... x.... |] It would be extra nice if I could reify the type of "x" in the following code. Of course the problem is that we don't even know if "f" (or "g" for that matter) is going to type check until we've spliced it. So we can only reify "x"'s type at splice time. I need the ability to reify "x"'s type and then, based on the information I get back, transform the block of declarations, "ds", in a certain manner. So I would in effect be doing a kind of "speculative splice". But a splice of top-level declarations can only occur at the top level! What I'm suggesting would be a speculative splice inside the body of a function, something that will ONLY work when the DecQ that we are splicing only contains Names that refer to functions in other modules or within the DecQ. (That is, we can't have the functions referring to variables outside the DecQ but in the current module!). Fortunately, this condition is satisfied by the DecQs I wish to do reification in. I can understand why no one would want to write a "reify" function as described above. But the only reason I've been throwing functions in [d| |] brackets is because I can't reify entire modules. (We would have to bloat .hi files for this to be the case.) But, say this were possible. Then it would be MUCH easier to code a reify function that could return the types of local Names, because we would already known that the module which we are reifying type checks and then in the bloated .hi files we could simple annotate each occurrence of a Name with its type. This would be extremely useful to me. Cheers, Sean

1 0

RE: [Template-haskell] TH stability and support
by Simon Peyton-Jones 17 Nov '03

17 Nov '03

The broad outlines of TH are stable, but there are likely to be changes. For example, the details of the data type representing Haskell terms might change. But I don't think anything significant will disappear -- new stuff may well appear. Yes, we do plan to support TH in GHC for the foreseeable future. As to other implementations, remember the economics of compilers. All Haskell implementations are built and maintained by volunteers. Within the effort budget we can individually afford, we each adjust our priorities based in part on what our users want. If lots and lots of people start using TH and ask for it in (say) Hugs, that'll make it more likely that it'll get done. But it's not a small feature to add, so I wouldn't plan on it any time soon. Simon | -----Original Message----- | From: template-haskell-bounces(a)haskell.org [mailto:template-haskell-bounces@haskell.org] On | Behalf Of Wolfgang Jeltsch | Sent: 15 November 2003 13:46 | To: Template Haskell Mailing List | Subject: [Template-haskell] TH stability and support | | Hello, | | is Template Haskell likely to be implemented in Hugs and/or NHC in the nearer | future? I think, TH could be very useful for me but actually I don't want to | restrict myself to a certain compiler/interpreter. Can I be sure that TH will | continue to be supported by GHC? | | I addition, I'd like to know if TH is rather stable now or if its interface | will make bigger changes in the future. | | Ciao, Wolfgang | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

1 0