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

[Trevor Smith]

Jeremy,

Your interface is kind of cool! There's something kind of fun about your
futures. However, I do think it adds complexity that perhaps is not needed.

I actually like the approach you suggested (earlier on this thread) of
using an abstract type and hand-creating accessors to the needed fields. I
like this approach because it does not add new ideas to the client's head.
Specifically, it would reuse the notion of an abstract type (which they
already are familiar with). Then the user needs to 1) ferry the size of the
type into Ocaml (my example does not currently do this, but this is
straightforward) and 2) generate the accessor functions (accessor generation
<https://github.com/trevorsummerssmith/ocaml-libuv/blob/test-lifecycle/lib_gen/libuv_accessor_gen.ml>
, ml accessors
<https://github.com/trevorsummerssmith/ocaml-libuv/blob/test-lifecycle/lib_gen/libuv_bindings.ml#L267>).
The code I wrote is a straightforward proof of concept that repeats a lot
of information.

However, *hand wave*, I think cstubs could be extended in a relatively
straightforward manor to generate this staged information, without
introducing new paradigms into the cstubs interface.

Thoughts? Thanks.

Trevor

On Mon, Nov 3, 2014 at 10:45 AM, Jeremy Yallop <yallop at gmail.com> wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/ctypes/attachments/20141103/fc38f9a4/attachment.html>