I'm not clear on exactly what the FastInt type means. I think I asked Alastair the same question recently - is FastInt an unlifted type?
Yes, it should be unlifted. Being unboxed as well would be nice but I'd sacrifice that for any other benefits like polymorphism and overloading.
Can I store it in a polymorphic data structure or pass it to a polymorphic function?
That would be highly desirable. I think it can be done using some kind of 'separate but equal' type system where we have two kinds of type variable: '*' for lazy types and '#' for strict types. So, for example, there would be two versions of 'id': id_* :: forall a::*. a -> a id_# :: forall a::#. a -> a My main question is how is a typechecker to infer kinds? Does it apply a default rule of '*' unless otherwise noted? What syntax does the programmer use to override that default? This would be a bit tedious because not only would be need to write strict and lazy versions of '+' (say) but we'd also have to define two separate Num-like classes: one for types of kind * and one for types of kind #. It would be really nice to have a single version of 'id' and a single definition of 'Num' but that would be hard to achieve because a piece of code like this: foo x = [bar (id (x + 1))] has a very different evaluation order depending on whether x is strict or lazy. I think we can implement it by passing round a dictionary that contains either 'seq' (for #) or '\ x y -> y' (for *) but that's not very appealing.
If FastInt is Int# in GHC, and we want it to be portable, then we have to introduce unlifted types & kinds in Hugs and nhc98 too.
Yes, I was proposing that Hugs and NHC be extended with unlifted types of some form.
Declaring instances of classes for unlifted types isn't possible, so you can't have instane Num Int#, for example. I think you need polymorphic kinds for that.
Yes, that was the conclusion I was slowly coming to above. -- Alastair Reid