For writing efficient emacs functions, would it be worthwhile/not too difficult to write a C wrapper for calling Julia functions or for calling Python functions via Numba/pycc?

For reference: Julia is a higher-level language designed for scientific computing that contains cfunction, a routine for efficiently passing Julia functions to C functions that accept function pointers. From what I gather, these functions are called more or less as efficiently as a native C function is called. Julia also happens to be able to call functions in many other languages very efficiently. Numba is a just-in-time compiler for Python that can also create C libraries using the command pycc. Both Julia and Python/Numba approach C-level performance for many tasks.

  • I suspect that unless you write a proper (read: persistent) bridge, any performance gains will be dwarfed by the time you need to boot up a process running the foreign code. So, please write a small demo first, then measure, then decide what approach to follow. – wasamasa Dec 18 '15 at 21:08
  • 3
    This appears to be multiple questions wrapped into one. Please separate out the question about lisp speed, the discussion about Julia and/or Python, and the question about wrappers to external programs. – Dan Dec 18 '15 at 21:40
  • I separated out the speed question. Most of the discussion about Julia is background for the primary question, so I am keeping it but making clear that it is subordinate to the question. Is that good? – Zorgoth Dec 18 '15 at 22:12
  • wasamasa: as I made more clear in the my edits to the second paragraph, I am talking about languages with specific methods of creating C-callable functions as machine code. – Zorgoth Dec 18 '15 at 23:09
  • You are aware that there is no FFI in Emacs? The closest thing to this is the relatively recent module support which requires you to write a dynamically loaded library in the same style of C as the core of Emacs is written in. – wasamasa Dec 18 '15 at 23:13

Browse other questions tagged or ask your own question.