<div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Thanks Julien. <br></div><div dir="auto"><div dir="auto">I think this is quite an interesting debate actually. </div><div dir="auto"><br></div><div dir="auto">I am taking the point of view of a more-or-less-advanced user in the course of writing an interface to an external C library.</div><div dir="auto">There are two independent sets of constraints to consider: Mercury language design constraints <font face="sans-serif">and performance issues of the interface when they are relevant. Actually the former may run contrary to the latter sometimes. So the question is what must yield first in such cases, and how to strike a reasonable balance.</font></div><div dir="auto"><br><span style="font-family:sans-serif"> > "<i>Why do you need to pass univs across the Mercury-C boundary?</i></span><i><br style="font-family:sans-serif"><span style="font-family:sans-serif">Why do you need to unpack them in C code?"</span></i><br><br>Performance issues. </div><div dir="auto">Consider an experimental user with a 50 GB database and a reasonably good platform.</div><div dir="auto">User has been performing 'second-wave IA' jobs (say ML neural network stuff for concreteness), say using R (but it might be TensorFlow and python). User now wants to process results in a 'third wave IA' perspective, in other words perform tasks:</div><div dir="auto">- using logic/functional programming techniques</div><div dir="auto">- using expert system methods modernized from good ol' 'first wave IA' (mostly symbolic rule-based analysis expressing some domain-specific knowledge).</div><div dir="auto"><br></div><div dir="auto">User now has to churn big data loads and wants to give Mercury a well-deserved chance. </div><div dir="auto"><br></div><div dir="auto">This is the context. It is not that experimental either, despite some appearances. It is even quite a trendy thing in some advanced IA curricula, with other tools/languages like Haskell. (Check out open-access IA courses at Zurich EPFZ for example).</div><div dir="auto"><br></div><div dir="auto">User now has to minimize Mercury/C interface overloads in a big data context. After some tests, he needs to thread his big data loads to and from R using the C FFI. </div><div dir="auto"><br></div><div dir="auto">Understandably, the data from R (and python is not better) will **not** be type-safe. R nastily and sometimes unpredictably casts types around, and User has to neutralize this by 'boxing' data flows into some universal data type. 'univ' looks like a good candidate ( at least a bit better than the string way out).</div><div dir="auto">User now has a choice: export some Mercury code into C to process the univ-typed 50 GB data, or use the runtime RTTI macros to do the job. Understandably s/he will prefer the latter option even in the face of possible interface modifications in the future: either the software C interface code will be fixed to reflect those changes, or the Mercury tools will be frozen at user level for the time it takes. This is mostly a team resource management issue, not a language design issue (from a user viewpoint).</div><div dir="auto"><br></div><div dir="auto"><span style="font-family:sans-serif">> "<i>The details of the RTTI system are deliberately not documented at the</i></span><i><br style="font-family:sans-serif"><span style="font-family:sans-serif">target language level since they are (and have been) subject to change."</span></i><br></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">Yes :-(</span></div><div dir="auto"><span style="font-family:sans-serif">Understandably so from a Mercury language developper's viewpoint. </span></div><div dir="auto"><font face="sans-serif">Perhaps a bit less so from a Mercury user's viewpoint, as outlined above.</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If you have to pack values in univs like that you would be far better<br>
implementing test/3 as a Mercury predicate and exporting that to C,<br>
e.g.<br>
<br>(...) <br><br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Great code chunk. Thanks again Julien.  I would suggest to add some version of it to Janet's nice crash course.</div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">> "<i><span style="font-family:sans-serif">I assume that you </span></i><i><span style="font-family:sans-serif">are attempting something a bit more general in practice?"</span></i></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><font face="sans-serif">Sure. As you understood, this was a simplified minimal example for demonstrative purposes. </font></div><div dir="auto"><font face="sans-serif">The real code is here (it runs, yet I must warn that it still is very unstable/experimental): </font></div><div dir="auto"><font face="sans-serif"><a href="https://www.github.com/fabnicol/RMercury/tree/library/ri.m" target="_blank" rel="noreferrer">https://www.github.com/fabnicol/RMercury/tree/library/ri.m</a>,</font></div><div dir="auto"><font face="sans-serif">lines 4100 and further down.</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">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.</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><font face="sans-serif">Fabrice</font></div><div dir="auto"><font face="sans-serif"><br></font></div><div dir="auto"><span style="font-family:sans-serif"><br><br></span></div></div>
</div></div>