FFI and disjoint types

FFI and disjoint types

[Ludovic Courtès]

Hello,

The nice thing about SMOBs is that they allow disjoint C types to be
mapped to disjoint Scheme types.

With ‘(system foreign)’, C pointers are mapped to Scheme foreign
objects, regardless of the type of object pointed to.  Thus, to get
disjoint types in Scheme, foreign objects would need to be boxed in
structs (since structs are the only way to create disjoint types from
Scheme).

If this analysis is correct, the resulting code may be somewhat
inefficient since we end up boxing C pointers twice.

Is this correct?  Thoughts?

Thanks,
Ludo’.

Re: FFI and disjoint types

[Neil Jerram]

ludo@gnu.org (Ludovic Courtès) writes:

> Hello,
>
> The nice thing about SMOBs is that they allow disjoint C types to be
> mapped to disjoint Scheme types.
>
> With ‘(system foreign)’, C pointers are mapped to Scheme foreign
> objects, regardless of the type of object pointed to.  Thus, to get
> disjoint types in Scheme, foreign objects would need to be boxed in
> structs (since structs are the only way to create disjoint types from
> Scheme).
>
> If this analysis is correct, the resulting code may be somewhat
> inefficient since we end up boxing C pointers twice.
>
> Is this correct?  Thoughts?

Sounds reasonable.  Perhaps (system foreign) could add a way of
declaring foreign pointer types, and of allowing code to state the type
of a pointer at the time of boxing it.

     Neil

Re: FFI and disjoint types

[Andy Wingo]

Hi,

On Mon 01 Mar 2010 15:18, ludo@gnu.org (Ludovic Courtès) writes:

> With ‘(system foreign)’, C pointers are mapped to Scheme foreign
> objects, regardless of the type of object pointed to.  Thus, to get
> disjoint types in Scheme, foreign objects would need to be boxed in
> structs (since structs are the only way to create disjoint types from
> Scheme).
>
> If this analysis is correct

It is

> the resulting code may be somewhat
> inefficient since we end up boxing C pointers twice.

Do you think this is an issue? We could add an extra word to foreign
pointers to make them have a type tag; or we could change the foreign
pointer representation to have a vtable. The downside with that is that
you can't allocate static foreign pointers that way.

I have a feeling that "double-wrapping" will perform fine. I figure a
high-level FFI will wrap these primitive foreign pointers in such a way
that they can preserve typing information, and hide the primitive
foreign pointer (if appropriate). But I could be wrong about that!

Cheers,

Andy
-- 
http://wingolog.org/