<div dir="ltr"><div>Hello,</div><div>  The first bullet point for the Python Compilers Workshop talks about passing JIT'ed code to wrapped C-functions.  Let me describe some work on a special case, which may be useful for the discussion.</div><div>  The starting point was the scipy integration routines (quad, etc) that accept a native function for the integrand callback.  I wrote a Sympy to LLVM JIT that would compile expressions into callbacks for scipy quad, and then extended that to several other libraries.</div><div><br></div><div>There is a longer description here:</div><div><a href="https://markdewing.github.io/blog/posts/integration-callbacks/">https://markdewing.github.io/blog/posts/integration-callbacks/</a></div><div><br></div><div>The python wrappers around the Cubature and Cuba libraries required modifications to accept native code callbacks.  It seems any wrapper around a native code library that uses</div><div>callbacks will need code to handle a native code callback vs. a Python callback.</div><div> For details, see these pull requests:</div><div>     <a href="https://github.com/saullocastro/cubature/pull/16">https://github.com/saullocastro/cubature/pull/16</a></div><div>     <a href="https://github.com/JohannesBuchner/PyMultiNest/pull/73/files">https://github.com/JohannesBuchner/PyMultiNest/pull/73/files</a></div><div><br></div><div><br></div><div>One of the issues in generalizing this is how to scale to different libraries and callbacks without needing to program knowledge of each of them into Sympy.</div><div>There needs to be some way to describe the parameters expected in the callback, but it should be at a higher level than just C types - which ones are inputs, outputs, array lengths, etc.</div><div><br></div><div>Mark</div><div><br></div></div>