On Mon, Mar 12, 2012 at 6:45 AM, Simon Marlow wrote:

But I can only pass unboxed types to foreign prim.

...

Is this an intrinsic limitation or just an artifact of the use cases that have presented themselves to date?

It's an intrinsic limitation - the I# box is handled entirely at the Haskell level, primitives only deal with primitive types.

Ah. I was reasoning by comparison to atomicModifyMutVar#, which deals with unboxed polymorphic types, and even lies with a too general return type. Though the result there is returned in an unboxed tuple, the argument is passed unboxed. Is that implemented specially? But anyway, I suspect your first definition of unsafeIndex will be faster

than the one using foreign import prim, because calling out-of-line to do the indexing is slow.

Sure though, I suppose that balance of may shift as the side of the short vector grows. (e.g. with Johan it'd probably be 16 items).

Also pseq is slow - use seq instead.

Of course. I was being paranoid at the time and trying to get it to work at all. ;) what you really want is built-in support for unsafeField#, which is

certainly do-able. It's very similar to dataToTag# in the way that the argument is required to be evaluated - this is the main fragility, unfortunately GHC doesn't have a way to talk about things that are unlifted (except for the primitive unlifted types). But it just about works if you make sure there's a seq in the right place.

I'd be happy even if I had to seq the argument myself before applying it, as I was trying above. -Edward

On Tue, Mar 13, 2012 at 4:57 AM, Simon Marlow wrote:

On 12/03/2012 14:22, Edward Kmett wrote:

...

On Mon, Mar 12, 2012 at 6:45 AM, Simon Marlow mailto:marlowsd@gmail.com> wrote: But I can only pass unboxed types to foreign prim.

Is this an intrinsic limitation or just an artifact of the use cases that have presented themselves to date?

It's an intrinsic limitation - the I# box is handled entirely at the Haskell level, primitives only deal with primitive types.

Ah. I was reasoning by comparison to atomicModifyMutVar#, which deals with unboxed polymorphic types, and even lies with a too general return type. Though the result there is returned in an unboxed tuple, the argument is passed unboxed.

Is that implemented specially?

I'm a little bit confused.

atomicModifyMutVar# :: MutVar# s a -> (a -> b) -> State# s -> (# State# s, c #)

Is the "unboxed polymorphic type" you're referring to the "MutVar# s a"? Perhaps the confusion is around the term "unboxed" - we normally say that MutVar# is "unlifted" (no _|_), but it is not "unboxed" because its representation is a pointer to a heap object.

I was talking about the (a -> b). I used it because the extraction of 'c' rather than a proper pair was closest to my situation. A less confused example might be newArray# which accepts a polymorphic 'a'.

The problem is, that can't be done reliably. For dataToTag# the compiler automatically inserts the seq just before code generation if it can't prove that the argument is already evaluated, I think we would want to do the same thing for unsafeField#.

Fair enough. Thanks again. -Edward