I've been looking at the new Foreign structure. It is good to see that the family of callNretM functions has been eliminated by introducing cStar. I've updated a few examples to use the buildCall<N> functions and they appear to work.
With CInterface, I was avoiding the family of call<N> functions by implementing a single call function based on call_sym or call_sym_and_convert. I am trying to do something equivalent using Foreign.LowLevel based on the implementation in buildCall<N>withAbi. There is a problem: the field "updateML" is not accessible because 'a conversion is abstract. Am I right in thinking "updateML" is required for conversions involving cStar? If so, is there a way I can implement my own variant of a buildCall function?
Also - just an observation - in the functions buildCall<N>withAbi, couldn't the argument offsets (and the amount of memory to malloc) be calculated once, rather than for each foreign call? E.g. in buildCall2withAbi:
let val callF = callwithAbi abi [arg1Type, arg2Type] resType fnAddr val arg1Offset = alignUp(#size resType, #align arg1Type) val arg2Offset = alignUp(arg1Offset + #size arg1Type, #align arg2Type) val argSize = arg2Offset + #size arg2Type in fn (a, b) => let val rMem = malloc argSize ...
Phil
On 16/12/2015 12:35, David Matthews wrote:
There have been a few changes to the Foreign structure. The callN functions have been renamed as buildCallN and the way functions are passed as arguments has been changed.
The reason for the changes is to make clear that the expensive operations are creating the C functions and closures and that calling a C function or passing a constructed closure are comparatively cheap.
It is important to call the buildXXX functions at the top-level e.g. in a structure, so that the C function is created once. The old callN functions were curried and it wasn't apparent that the partial application to the conversions was quite different to the application of this to the arguments. For that reason the buildXXX take a tuple.