Boxed foreign prim

[Edward Kmett]

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

> On 12/03/2012 14:22, Edward Kmett wrote:
>
>> On Mon, Mar 12, 2012 at 6:45 AM, Simon Marlow <marlowsd at gmail.com
>> <mailto:marlowsd at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120313/90a4af3b/attachment.htm>