[m-users.] Refactoring Mercury/C FFi code

[Zoltan Somogyi]

On Sun, 14 Jul 2019 23:08:13 +0100, emacstheviking <objitsu at gmail.com> wrote:
> My question then is what would be "the best way"
> to handle this case. With two rectangles I have had to create four
> predicates, with three it would be 8 etc etc and it feels like there is a
> better way.

The "best way" depends on information you haven't told us: whether
most of the code working on rectangles is in Mercury or in C.

If most of the code that manipulates values of a type is in C, then you should
define the type in C, and write foreign_proc predicates and/or functions to
export the needed functionality to Mercury code.

If most of the code that manipulates values of a type is in Mercury, then you should
define the type in Mercury, and write Mercury predicates and/or functions, exported
to C, to provide the needed functionality to C code.

If the code sample you gave is representative, then I would have a C declaration

typedef SDL_Rect *SDL_RectPtr;

and Mercury definitions

:- type sdl_rect;
:- pragma foreign_type(c, sdl_rect, "SDL_RectPtr").

   % Return the x and y coords, width and height of a rectangle if and only if non-null.
   %
:- pred sdl_rect_is_real(sdl_rect::in, int::out, int::out, int::out, int::out) is semidet.

Then you would need only one sdl_rendercopy predicate, which could do its
own null/nonnull tests as needed.

> From what I have learned so far I know that
> parameters are passed in as MR_Word sized values so would it be safe for
> example to cast an sdl_rect() declared as:
>  
> *:- type sdl_rect ---> sdl_rect(x::int, y::int, w::int, h::int).*
> 
> *typedef struct SDL_Rect{    int x, y;    int w, h;} SDL_Rect;*
> 
> to an SDL_Rect which has the same size and shape?!?!?!?!

No, that would not be safe. It may work with the current data representation
scheme used by the Mercury compiler, but that scheme may change.
I should know; I am working on such a change right now.

Zoltan.