[ocaml-ctypes] Defines, and Structs with platform-specific fields

[Jeremy Yallop]

On 30 October 2014 12:34, Trevor Smith <trevorsummerssmith at gmail.com> wrote:
> Thanks for this work! I just got a chance this morning to take a look. This
> work should save me a ton of time.
>
> I'm having problems referencing a cstub'd struct within another cstub'd
> struct. Looking at the types it doesn't seem that this would work  - the
> cstubs typ is different than the Ctypes.typ. I reproduced a tiny example in
> the cstubs test files (diff below).

Right: this is a difficulty with the current approach.  You can work
round it, of course, by generating each struct via a separate functor,
but that's terribly clunky, especially where there are self references
involved.

We really need to embrace the fact that the stub generation approach
involves staging, and make that explicit in the interface somehow.
David Sheets and I have considered adding an 'applicative' for staging
in the past, but I've been reluctant because it makes the interface
more complicated.

An interface with staging might work as follows: values, and
specifically values that represent types, are classified as either
'present' or 'future' according to whether we know about them now or
whether we have to generate some code to learn about them.  For
example, 'int' is present, since we know its size etc. now, but
'struct uv_loop_s' is future: we have to generate some C code to
determine its properties.  Present values can be used to build either
present or future values, but future values can only be used to build
future values: we don't get access to the future in advance.

The interface looks like this:

    https://github.com/yallop/ocaml-ctypes/blob/staged-struct-stubs/src/cstubs/cstubs_structs.mli

There are a couple of extra functions !^ and <*> for lifting present
values into the future and for future application, and the structure,
union, etc. functions now create future typ values rather than values
of an abstract type.  In practice it looks much the same as before,
except for a little extra syntactic noise when you use a present value
in a future definition -- for example, when you build a future struct
definition with an int field:

   https://github.com/yallop/ocaml-ctypes/blob/staged-struct-stubs/src/cstubs/cstubs_structs.mli#L16-L17

Is this approach intelligible?  Overly complex?  Thoughts welcome.