> On 1 Dec 2022, at 13:57, Christian Lindig <christian.lin...@citrix.com> wrote: > > > >> On 1 Dec 2022, at 13:50, Edwin Torok <edvin.to...@citrix.com> wrote: >> >> Should we instead switch to using ctypes to generate these constants? > > I would not advocate this. Ctypes is the kind of meta programming that is > great when it works but hell if it does not and it adds more dependencies.
Perhaps use it to just generate the constant mappings? Here is an example of how I used it elsewhere: https://github.com/xapi-project/ocaml-dlm/blob/master/lib_gen/types/bindings_structs.ml#L30-L55 > > I just had a discussion with Andrew about other tricks how to bring C > constants to the ML side in order to decouple them. I’m using it in my Polly > library - it might not be the solution for Xen but worth knowing. > > https://github.com/lindig/polly/blob/master/lib/polly_stubs.c#L23-L39 The disadvantage is that we can't pattern match on it anymore. Although we could have some OCaml code that does the pattern matching on another type and maps it to these private integer types. However at that point we've manually reinvented what ctypes would already do, and we have an additional mapping step (which may not matter from a performance point of view but would be nice if we could avoid it). I'll have to do some experiments to see how the code generated by ctypes looks like in this case (actually the 'cstubs' part of it), and how different it would be from manually writing it (i.e. can we still reasonably review the generated code, and would it look like something that we'd write ourselves?) Best regards, --Edwin
