Replies: 2 comments
-
Please look at this work from @edwintorok : https://arxiv.org/abs/2307.14909
This is of general interest, but in particular it has a tool building C files from OCaml external declarations, to have a C compiler check the consistency with the actual C implementations. |
Beta Was this translation helpful? Give feedback.
-
One difficulty here is the lifetime of the underlying OCaml values. Normally external calls do not keep their value arguments alive, it is the callee's responsibility to root the values if they are still useful. For unboxed numeric arguments, the OCaml-side values are discarded and may be collected during the external call computation. For custom values this approach would be incorrect, as this means that the GC could call the custom finalizer in the middle of the C function call. The only approach I see is to decide that custom blocks should remain alive for the whole duration of the external call, artificially extending the duration compared to normal function arguments. This requires low-level changes to parts of the compiler I don't know about (the static computation of local roots). I am hesitant about a mostly-cosmetic feature requiring such ad-hoc changes to the compiler. (Thinking about this more: we cannot easily do this statically when computing local roots, because at that point we may not know which values will dynamically receive custom blocks. We could either use a separate unboxing annotation for this -- that extends the lifetime of the OCaml block -- or insert a dynamic check for custom blocks to be rooted dynamically. The separate unboxing annotation feels more reasonable, but it means that users who forget to use it will get random crashes in their programs.) |
Beta Was this translation helpful? Give feedback.
-
Following the PR #12375, I wish to work more on improving the C binding. Gaining both efficiency and reliability.
Here are a few ideas:
FLAGS (issue #12366)
These are very frequent in C library. I do not like the list approach (allocates and slow) I see two directions:
@gasche and @yallop in the above mentioned issue prefer the first solution. I prefer the second, because for OpenGL/EGL, writing the function is really painfull as there are many contants. A mixed approach is a ppx, but I owuld like support in the base compiler.
Remark: conversion of immediate types to int allows for indexing an array.
Unix.file_descr
These are not recognize as immediate types because they are not integer on windows. A function doing the conversion to int in both direction would be nice. It also allows for sending file_descr over channel as 8 or even 4 bytes instead of 21 with Marshall.
String and bytes as arguments
They do not require any flags, as they are represented by a C compatible pointer. But if one look at write/read and many other function, an offset would be nice. example
Custom blocks (including bigarrays), as arguments
Would be nice to allow to use [@unbox] on them (or create a specific tag)
Verification
There is no check that types agree between the external declaration and the C implementation. For a language that is "strongly statistycally typed" this sounds like a problem. I see two ways
The second approach is simpler and has no dependencies. @yallop ctypes does that job, could be integrated in the compiler ?
More int size available
Currently, untagged should corresponds to natint. I would be nice if char/short, etc would be available, and if OCaml generates some C file with some ##if directive, it seems feasible. This also requires more code to emit the call to C
Beta Was this translation helpful? Give feedback.
All reactions