- template-haskell - Haskell.org

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

RE: [Template-haskell] unexpected behaviour
by Simon Peyton-Jones 15 Apr '03

15 Apr '03

| -----Original Message----- | out' :: Dec -> () | out' _ = () | | outGen' :: Q [Dec] | outGen' = do d<-reifyDecl Tree | dec1<-clause [pvar "x"] (normal [|out' d|]) [] | return [Fun "out" [dec1]] | | I get an unexpected: | No instance for (Lift Dec) arising from use of `d'... The lifting thing is described (somewhat) in the paper. The idea is that [| out' d |] builds some code (i.e. a data structure) for later execution. That code needs 'd', but d may not be in scope where the code is executed. So the code must include code to build d. That's what lifting does. Yes, Dec could be made liftable, but it's unlikely to be what you want. | Whereas if I replace outGen' by: | | foo :: Q () | foo = do d<-reifyDecl Tree | return (out' d) | | outGen :: Q [Dec] | outGen = do dec1<-clause [pvar "x"] (normal [|foo|]) [] | return [Fun "out" [dec1]] or you could, I think, say | foo :: Q Dec -> Q () | foo qd = do d<-qd | return (out' d) | | outGen :: Q [Dec] | outGen = do let d = reifyDecl Tree | dec1<-clause [pvar "x"] (normal [|foo d|]) [] | return [Fun "out" [dec1]] | Now another thing: after writing some code randomly, I happened to | write foo like this: | | foo :: Q () | foo = do d<-reifyDecl Tree | return $( [| out' d |] ) | | Because I meant that the "out' d" should really be executed _before_. | Now, I understand this was not really sensible (or was it ?). No I don't think so. It should be the case that $[| e |] = e for any e. | However, ghc gives an ugly "panic!" message upon this, which is not | nice, and I suppose had to be reported. Yes, that's a bug, thank you. Simon

1 0

RE: [Template-haskell] instance declarations
by Simon Peyton-Jones 15 Apr '03

15 Apr '03

| More generally, is there some kind of comprehensive up-to-date | documentation for this kind of questions ? Yes indeed: look in libraries/haskell-src/Language/Haskell/THSyntax You can get that from the CVS respository (which is easy to access in read-only mode). Simon

1 0

unexpected behaviour
by François-Régis Sinot 15 Apr '03

15 Apr '03

Hello everybody I am new to the list and intend to bother you a bit in the near future with newbie questions --- my apologies in advance. The following seems strange to me. If I try: data Tree a = Leaf a | Bin (Tree a) (Tree a) out' :: Dec -> () out' _ = () outGen' :: Q [Dec] outGen' = do d<-reifyDecl Tree dec1<-clause [pvar "x"] (normal [|out' d|]) [] return [Fun "out" [dec1]] I get an unexpected: No instance for (Lift Dec) arising from use of `d'... Whereas if I replace outGen' by: foo :: Q () foo = do d<-reifyDecl Tree return (out' d) outGen :: Q [Dec] outGen = do dec1<-clause [pvar "x"] (normal [|foo|]) [] return [Fun "out" [dec1]] Then everything works OK. Is it really a bug or just one of the numerous staging problems ? Shouldn't everything derive Lift, by the way ? (if useful) Now another thing: after writing some code randomly, I happened to write foo like this: foo :: Q () foo = do d<-reifyDecl Tree return $( [| out' d |] ) Because I meant that the "out' d" should really be executed _before_. Now, I understand this was not really sensible (or was it ?). However, ghc gives an ugly "panic!" message upon this, which is not nice, and I suppose had to be reported. Cheers, fr.

1 0