[m-users.] Fwd: Documenting univ data passing to and from the C FFI

[Julien Fischer]

Hi Fabrice,

On Thu, 20 May 2021, Fabrice Nicol wrote:

> Yes :-(
> Understandably so from a Mercury language developper's viewpoint. 
> Perhaps a bit less so from a Mercury user's viewpoint, as outlined above.
>
>       If you have to pack values in univs like that you would be far better
>       implementing test/3 as a Mercury predicate and exporting that to C,
>       e.g.
>
>       (...) 
> 
> 
> Great code chunk. Thanks again Julien.  I would suggest to add some
> version of it to Janet's nice crash course.  Unfortunately, I tested
> it against a realistic database and the incurred CPU time penalty is a
> bit stiff over the C RTTI macro alternative (link below).

I would be surprised if it were not slower, given that it does more
work than the macro ;-)

> > "I assume that you are attempting something a bit more general in practice?"
> 
> 
> Sure. As you understood, this was a simplified minimal example for demonstrative purposes. 
> The real code is here (it runs, yet I must warn that it still is very unstable/experimental): 
> https://www.github.com/fabnicol/RMercury/tree/library/ri.m,
> lines 4100 and further down.
> 
> I'm following a mixed approach there: using 'MR_unravel_ univ' at the
> C level yet performing type analysis in Mercury code. This is OK while
> you have few columns. But this might have to be changed for transposed
> matrices with millions of columns (and few lines), as in this case
> Mercury code type analysis would be called as many million times.

Looking at that code I note that the only values you pack into univs
have a known set of types: bool, int, float and string.  As Zoltan
mentioned using univ here is the wrong choice; you should use a type
that encodes what the type of the underlying value is as part of the
type, e.g.

     :- type myuniv
          --->    b(bool)
          ;       i(int)
          ;       f(float)
          ;       s(string).

That would avoid your use of RTTI operations to look up type names and
the resulting calls to strcmp() in the bodies of the various
compose_to_univ_* foreign_procs.

(Aside: looking at the R documentation it seems that R's ints are
32-bit, so perhaps that should be int32 above not an int.)

Julien.