April 2003 - template-haskell

RE: [Template-haskell] Release
by Simon Peyton-Jones 23 May '03

23 May '03

| As I understand it the GHC team are heading towards a release including | TH in the not too distant future. I think it would be good if the | biggest outstanding issues could be fixed before then (and indeed, just | fixed ASAP). Yes, that's a good idea. | The one that causes me the most hoop jumping is the type parameters to | some of the TH datastructures. For example, I have some code like this: It's all to do with Tim's "two-level types" scheme, but I do agree with you that it seems more trouble than its worth. Tim: how vigorously do you want to defend this? If not, can we let Ian remove the parameterisation? Simon | -----Original Message----- | From: template-haskell-admin(a)haskell.org [mailto:template-haskell- | admin(a)haskell.org] On Behalf Of Ian Lynagh | Sent: 08 April 2003 13:17 | To: template-haskell(a)haskell.org | | | As I understand it the GHC team are heading towards a release including | TH in the not too distant future. I think it would be good if the | biggest outstanding issues could be fixed before then (and indeed, just | fixed ASAP). | | The one that causes me the most hoop jumping is the type parameters to | some of the TH datastructures. For example, I have some code like this: | | class ToDec a where | to_dec :: a -> Dec | | instance ToDec Dec where | to_dec = id | | class ToExp a where | to_exp :: a -> Exp | | instance ToExp Exp where | to_exp = id | | instance (ToExp e, ToDec d) => Foo (Match p e d) where | foo (Mat p (Normal e) ds) = bar (Normal (Let (map to_dec ds) (to_exp e))) | | Which I'd much rather be able to write as | | instance Foo Match where | foo (Mat p (Normal e) ds) = bar (Normal (Let (map to_dec ds) (to_exp e))) | | Previous discussions about this have all petered out before reaching a | conclusion, but I haven't seen anyone actually stand up and defend the | parameterised types, and it's hard to see how they could be useful | without everything being parameterised anyway. Can we get rid of them? | Please? Or at least have an explanation of why not... | | Hmmm, or maybe I should be asking for them to be extended to cover all | the types to make it easier to have a type of reification that annotates | the tree with type and strictness information. I'd still have the | problem above, but at least more things would be possible. | | Anyway, I'm confused, but sitting in the middle is just driving me mad! | | | Thanks | Ian | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

4 4

RE: [Template-haskell] Representation of unboxed primitives in TH
by Simon Peyton-Jones 01 May '03

01 May '03

OK. Ian, I suggest that if you want to put the unboxed stuff in meanwhile, then go ahead. Simon | -----Original Message----- | From: Tim Sheard [mailto:sheard@cse.ogi.edu] | Sent: 30 April 2003 16:27 | To: Simon Peyton-Jones; Ian Lynagh; Simon Peyton-Jones | Cc: Sean Seefried; template-haskell(a)haskell.org | | At 12:25 PM 4/30/2003 +0100, Simon Peyton-Jones wrote: | >I'd like to hear from Tim Sheard. Tim: do you have an opinion? | | My original goal was for the data-structure that represented code | to be as simple as possible. But I can see that this isn't going | to work, since users want to "represent" any program they can write | in GHC, and that includes (generally) all the GHC extensions. | | I guess we need a strategy to address these things. This is some thing | we should address when I come to Cambridge next month. | | Tim Sheard |

1 0

RE: [Template-haskell] Representation of unboxed primitives in TH
by Tim Sheard 01 May '03

01 May '03

At 12:25 PM 4/30/2003 +0100, Simon Peyton-Jones wrote: >I'd like to hear from Tim Sheard. Tim: do you have an opinion? My original goal was for the data-structure that represented code to be as simple as possible. But I can see that this isn't going to work, since users want to "represent" any program they can write in GHC, and that includes (generally) all the GHC extensions. I guess we need a strategy to address these things. This is some thing we should address when I come to Cambridge next month. Tim Sheard

1 0

RE: [Template-haskell] Representation of unboxed primitives in TH
by Simon Peyton-Jones 01 May '03

01 May '03

| > Would you like to check I'm right, and perhaps add a test to | > testsuite/tests/ghc-regress/th/? | | I don't think I can make it break, so I'm afraid I can't do this! Tests can succeed, you know! Many of our tests are things that should work, but broke in the past -- this is a good example. | Where do we stand on unboxed values? As I understand it Sean wants to | use them but you aren't keen on them due to datastructure bloat. I'd like to hear from Tim Sheard. Tim: do you have an opinion? Simon

2 1

RE: [Template-haskell] Representation of unboxed primitives in TH
by Simon Peyton-Jones 30 Apr '03

30 Apr '03

OK, I get it. You are right. But what you have missed is that there's a bug in the existing code for repLiteral. Given an HsInt, dsLit will produce a CoreExpr of type Int (not Integer), and that's incompatible with the 'integerL' that'll be applied to it. So you need to do the same thing for HsInt as you've done for HsIntPrim. Presumably this doesn't come up much, or we'd have tripped over it already. Would you like to check I'm right, and perhaps add a test to testsuite/tests/ghc-regress/th/? Thanks Simon | -----Original Message----- | From: Ian Lynagh [mailto:igloo@earth.li] | Sent: 22 April 2003 22:17 | To: Simon Peyton-Jones | Cc: Sean Seefried; template-haskell(a)haskell.org | | On Tue, Apr 22, 2003 at 03:55:44PM +0100, Simon Peyton-Jones wrote: | > I'm not certain that your fix is right, Ian. You are saying that | > | > (I# 30#) | > | > is represented in THSyntax is | > | > (I# 30) | | No, this is *in addition* to having a new sort of Lit etc. The problem | seemed to be that dsLit was returning a different sort of value - I | forget the details now - for IntPrims to Int and Integers, so I rewrote | the literal for just that phase. I'm now wondering if it was making it | an Int while I was using it as an Integer. | | Which brings me to another question - in the HsLit datatype an Int# is | stored as an Integer - why not an Int? | | I've attached the diff which I hope will make it clearer. | (The HEAD seems to be broken again so I can't test this, but I *think* | I've got everything in). | | > The question is whether you want to be able to represent unboxed Ints in | > THSyntax, which is meant to be "nice and simple". Perhaps yes, because | > you want to get GHC extensions through it; in that case THSyntax.Lit | > would need an extra constructor. But perhaps no, because it's meant to | > be simple. The more that gets added to THSyntax, the more any program | > analysing THSyntax needs to do. | | Well, it's already more than Haskell98, so I didn't think there would be | any problem extending it to cover everything. I guess you could argue | the other things are being developed in the hope they will go into | Haskell 2, though. | | Programmers are free to return an error if given a non-H98 | datastructure, although it is a pity Haskell has no way to allow you to | define a function on a subset of a datatype so warnings of unhandled | cases would still be useful. | | | Thanks | Ian |

2 1

RE: [Template-haskell] Representation of unboxed primitives in TH
by Simon Peyton-Jones 23 Apr '03

23 Apr '03

I'm not certain that your fix is right, Ian. You are saying that (I# 30#) is represented in THSyntax is (I# 30) When that is translated back to HsSyn, it'll lack the '#', which in turn will mean that you'll get an overloaded literal 30, which can't be instantiated to Int#. So my guess is that this will fail at the splice point. No time to try it -- I'm about to go on holiday for 2 wks. The question is whether you want to be able to represent unboxed Ints in THSyntax, which is meant to be "nice and simple". Perhaps yes, because you want to get GHC extensions through it; in that case THSyntax.Lit would need an extra constructor. But perhaps no, because it's meant to be simple. The more that gets added to THSyntax, the more any program analysing THSyntax needs to do. Simon | -----Original Message----- | From: template-haskell-admin(a)haskell.org [mailto:template-haskell-admin@haskell.org] On Behalf Of | Ian Lynagh | Sent: 19 April 2003 19:50 | To: Sean Seefried | Cc: template-haskell(a)haskell.org | | On Sat, Apr 19, 2003 at 11:38:11PM +1000, Sean Seefried wrote: | > I am writing some code in Template Haskell which I hope to use to | > transform code. One thing I want to do is replace integers and Rationals | > with their unboxed equivalents. However, Template Haskell doesn't support | > this. | | I've just tried this in my local tree (only done IntPrim) and it was all | as you say (assuming you also made the necessary changes to | hsSyn/Convert.lhs too) but I also needed to change repLiteral in | deSugar/DsMeta.hs as this bit of diff shows: | | repLiteral :: HsLit -> DsM (Core M.Lit) | repLiteral lit | - = do { lit_expr <- dsLit lit; rep2 lit_name [lit_expr] } | + = do { lit_expr <- dsLit lit'; rep2 lit_name [lit_expr] } | where | + lit' = case lit of | + HsIntPrim i -> HsInteger i | + _ -> lit | lit_name = case lit of | HsInteger _ -> integerLName | HsInt _ -> integerLName | + HsIntPrim _ -> intPrimLName | HsChar _ -> charLName | HsString _ -> stringLName | HsRat _ _ -> rationalLName | | I haven't looked into this in detail, but I'm sure Simon will jump up if | it is the wrong thing to do. I probably won't be committing until the | HEAD builds. | | | Thanks | Ian | | _______________________________________________ | template-haskell mailing list | template-haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/template-haskell

2 1

Representation of unboxed primitives in TH
by Sean Seefried 20 Apr '03

20 Apr '03

I am writing some code in Template Haskell which I hope to use to transform code. One thing I want to do is replace integers and Rationals with their unboxed equivalents. However, Template Haskell doesn't support this. The relevant error message, triggered by the following expression: $([| 20# |]) is: DsMeta.repLiteral: trying to represent exotic literal I naively tried to add support for the representation of unboxed types by adding the following clauses to repLiteral HsIntPrim _ -> intPrimLName HsFloatPrim _ -> floatPrimLName HsDoublePrim _ -> doublePrimLName I then added the relevant *IdKey and *Name definitions and added the following constructors to the Lit type in THSyntax.hs IntPrim, FloatPrim, DoublePrim. I had a feeling this wouldn't work. I mean, they're obviously "exotic" and my suspicion was confirmed when I got segmentation faults compiling the code. main = putStrLn (show $([| I# 20# |])) My question then is, why are they hard to represent? What is it that I am missing? Sean Seefried

2 1

RE: [Template-haskell] Release
by Simon Peyton-Jones 19 Apr '03

19 Apr '03

| Moreover, I would like to propose the following: | | * Use a naming scheme for the functions that avoids having | to suffix some with "E" or "D" and some not. Example: we | have "cond", but "letE". Better *uniformly* use a single | suffix for all functions of the same class; eg, "condExp" | and "letExp" (or "condE" and "letE" if you desperately | want to save letters). | | * Get rid of the intriguing (but IMHO impractical) idea of | using mnemonics of a particular length for variants data | types. Example: we have "Mat" and "Mtch" as well as "Rhs" | and "Rihs", where the four letter variant is in the Q | monad. The distinction between "Mat" and "Match" etc will | vanish once we get rid of the two-level type scheme. Then | we can just have "Match" and "MatchQ" together with "Rhs" | and "RhsQ" and so on. I have no axe to grind here. As far as I am concerned, anything that meets with others' approval is fine with me. So, you merry and select band of TH users, speak up now, else Ian and Manuel will change it anyway! Simon

2 1

RE: [Template-haskell] unexpected behaviour
by François-Régis Sinot 15 Apr '03

15 Apr '03

1 0

instance declarations
by François-Régis Sinot 15 Apr '03

15 Apr '03

Hi Could anyone recall me the syntax for instance declarations ? (eg what form should have the 2nd argument to Instance ?) My best guess was something like: genReg' :: Q [Dec] genReg' = do dec1<-fun "out" [clause [pvar "x"] (normal [|foo|]) []] ctx1<-ctxt [] clss<-tapp (tcon (TconName "Regular")) (tcon (TconName "Tree")) return [Instance ctx1 clss [dec1]] intended to produce something like: instance Regular Tree where out x = ... But it gives a kind error on Tree: Kind error: `Tree' is not applied to enough type arguments When checking kinds in `Regular Tree' In the instance declaration for `Regular Tree' More generally, is there some kind of comprehensive up-to-date documentation for this kind of questions ? Thanks, fr.

1 1