MLton / mlton

The MLton repository
http://mlton.org
Other
962 stars 127 forks source link

FFI suggestion: allow array slices to be passed to C functions #516

Closed athas closed 1 year ago

athas commented 1 year ago

MLton's FFI allows arrays to be passed directly to C, which is very convenient. It would be similarly convenient to also allow array slices to be passed. It should be pretty easy to implement: just increment the array data pointer by the slice offset before calling the C function.

Right now I don't know of anyway way to get foreign C functions to write their results in the middle of an array.

MatthewFluet commented 1 year ago

MLton's FFI allows arrays to be passed directly to C, which is very convenient. It would be similarly convenient to also allow array slices to be passed. It should be pretty easy to implement: just increment the array data pointer by the slice offset before calling the C function.

It's easy at the codegen point, but the compiler has no native support for slices. They are purely an SML construct in the Basis Library: https://github.com/MLton/mlton/blob/master/basis-library/arrays-and-vectors/sequence0.sml#L147-L153. It would be significant effort to "teach" the compiler about slices and carry them through the entire compilation process.

Right now I don't know of anyway way to get foreign C functions to write their results in the middle of an array.

The suggestion would be to pass the array and the offset to C and let C do the pointer arithmetic. Admittedly, this requires a "wrapper" C function if you are simply trying to get an interior pointer to pass to an existing C function. But, it is essentially what MLton does to implement ARRAY_SLICE.copy{,Vec} with a memmove: https://github.com/MLton/mlton/blob/master/runtime/gc/sequence.c#L73-L94.

athas commented 1 year ago

I see. Maybe my preference for not having to write glue C code is irrational. The only workaround I can think of would be for the FFI to treat a pair (array, int) as a sign to increment the pointer appropriately. Feels a bit ad-hoc, but I would personally be OK with it. But I'm closing the issue anyway, since my original suggestion doesn't really work out.