Boxed foreign prim

Edward Kmett ekmett at
Tue Mar 13 16:07:10 CET 2012

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

> On 12/03/2012 14:22, Edward Kmett wrote:
>> On Mon, Mar 12, 2012 at 6:45 AM, Simon Marlow <marlowsd at
>> <mailto:marlowsd at>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Glasgow-haskell-users mailing list