[Template-haskell] Representation of unboxed primitives in TH

[Simon Peyton-Jones]

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@haskell.org
|=20
| 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)
|=20
| 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.
|=20
| Which brings me to another question - in the HsLit datatype an Int# is
| stored as an Integer - why not an Int?
|=20
| 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).
|=20
| > 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.
|=20
| 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.
|=20
| 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.
|=20
|=20
| Thanks
| Ian
|=20