[Caml-list] CamlIDL and true abstract types

[Caml-list] CamlIDL and true abstract types

[Lauri Alanko]

Hello. I recently learned of CamlIDL (thanks to the list), and tried it out.
After trying it out for a while, it seems to me that an absolutely essential
feature is missing: abstract types.

With an abstract type I mean a type whose representation is known neither at
the C side nor in the caml world. Typically these are of the form:

typedef struct Foo_ Foo;

Where the actual definition of struct Foo_ is completely missing from public
headers, or even if it is not, its structure is supposed to be an
implementation detail. These sorts of types are needed often enough in many
bindings, and the Caml translation for Foo* should be clear:

type foo

Yet somehow there seems to be no direct way for doing this within CamlIDL.
How come?

Another funny thing about CamlIDL is that it translates everything _by
value_. C structs are transformed to newly allocated caml blocks and vice
versa. Yet often enough the _identity_ of the struct (ie. its physical
address) is essential. And though CamlIDL provides the "ptr" translation for
pointers, it uses Com.unique as the translation type instead of a pure
abstract type. And it provides no way to directly access or modify fields of
existing C structs.

To my mind, this makes CamlIDL unusable for creating bindings for anything
but the most simple-minded libraries. Yet many people seem to promote it.
Have I misunderstood something?


Lauri Alanko
la@iki.fi
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CamlIDL and true abstract types

[Dmitry Bely]

Lauri Alanko <la@iki.fi> writes:

> Hello. I recently learned of CamlIDL (thanks to the list), and tried it out.
> After trying it out for a while, it seems to me that an absolutely essential
> feature is missing: abstract types.
>
> With an abstract type I mean a type whose representation is known neither at
> the C side nor in the caml world. Typically these are of the form:
>
> typedef struct Foo_ Foo;
>
> Where the actual definition of struct Foo_ is completely missing from public
> headers, or even if it is not, its structure is supposed to be an
> implementation detail. These sorts of types are needed often enough in many
> bindings, and the Caml translation for Foo* should be clear:
>
> type foo
>
> Yet somehow there seems to be no direct way for doing this within
> CamlIDL.

Read the manual more carefully :-)

typedef [abstract] void* Foo;

is what you need. Don't miss also finalize() attribute; it may be quite
useful for you.

Hope to hear from you soon,
Dmitry


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CamlIDL and true abstract types

[Lauri Alanko]

On Sat, May 18, 2002 at 11:03:17AM +0400, Dmitry Bely wrote:
> Read the manual more carefully :-)
> 
> typedef [abstract] void* Foo;

Yes, I read about that, but I consider it a hack, not proper support.
Since CamlIDL considers Foo completely opaque and doesn't even see that
it is a pointer, I cannot use pointer-specific attributes such as [ref],
[unique] and [ignore]. And saying that a type is void* when it really is
Foo* isn't even strictly legal, the way the stubs are implemented:
though conversion between void* and T* is legal for all object types T,
conversion between void** and T** isn't, yet this is the sort of type
punning that the generated stub code does.


Lauri Alanko
la@iki.fi
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] CamlIDL and true abstract types

[Dmitry Bely]

Lauri Alanko <la@iki.fi> writes:

>> typedef [abstract] void* Foo;
>
> Yes, I read about that, but I consider it a hack, not proper support.

I don't think so. IMHO the support is quite sufficient.

> Since CamlIDL considers Foo completely opaque and doesn't even see that
> it is a pointer, I cannot use pointer-specific attributes such as [ref],
> [unique] and [ignore].

Why do you need these attributes for abstract types? How are you going to
use them? What should they mean?

>  And saying that a type is void* when it really is
> Foo* isn't even strictly legal, the way the stubs are implemented:
> though conversion between void* and T* is legal for all object types T,
> conversion between void** and T** isn't, yet this is the sort of type
> punning that the generated stub code does.

I don't see the real problem here.

1. Conversion that stub funtions perform is always safe.
2. You can compile the stub with your library C headers, and then there
will be no conversion at all, because the original definition of type Foo
will be used:

test.idl
typedef [abstract] void* Foo;

test.h
/* manually written */
#include "foo_native_definition.h"

$ camlidl test.idl

Hope to hear from you soon,
Dmitry


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners