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