Marco Zocca <[email protected]> writes:

> The host language is Haskell; 

Cool!

> so far I've managed to wrap Petsc structures made up of elementary
> types and with no macros inside (e.g.  _n_PetscLayout ), and Petsc
> functions that operate on typedefs of elementary types
> (e.g. PetscInitialize() ).  _p_Vec and similar are proving harder to
> implement. (Haskell requires one to write instances of a certain
> typeclass Storable,

No, don't write instances for _p_Vec, write them for Vec (the opaque pointer).

> that add pointer-like functionality to the instanced datatypes) On the
> other hand, I cannot treat Vec, Mat etc. simply as a opaque pointers
> because Petsc uses them both by value and by reference.

No, we never pass the struct.  (It's not even visible to C callers.)  We
pass Vec (i.e., struct _p_Vec*) and Vec* (e.g., for return values).  As
far as any caller is concerned, Vec is just a value.  You never need to
know that it is a pointer instead of an integer.  Indeed, we could
change the typedef to uintptr_t and use the value as a lookup index into
a private data structure and existing callers would not even need to
recompile (on almost all platforms).  (This transformation would
negatively impact debugging.)  There is nothing you can possibly do if
you know that it is a pointer.

Attachment: signature.asc
Description: PGP signature

Reply via email to