The last time I looked at the Nim documentation, one had to manually declare C and C++ functions. I don't see how that's different from pretty much any other language that can call C (i.e. pretty much all of them). Then there's preprocessor macros.
That's nice, but not the same - users have to intend to write a Python extension in Nim. With autowrap, you can call unmodified D code (and as shown in the blog, C code as well with dpp). That means code that was never meant for consumption from another language can be made available.
You don't need to modify the code, just add a wrapper.
Nothing prevents generating a wrapper automatically but 99% of the time that is not very useful.
The large majority of Python extension contain Python-specific code to access or return Python objects or act in a pythonic way.
You don't need to modify the code, just add a wrapper.
Still not the same.
Nothing prevents generating a wrapper automatically but 99% of the time that is not very useful. The large majority of Python extension contain Python-specific code to access or return Python objects or act in a pythonic way.
Except, and I cannot stress this enough, at work we're using this to succesfully call into D production code without any Python-specific anything. It just works. The article wasn't even about that, it's about making it work just as seamlessly for C.
Comments
The last time I looked at the Nim documentation, one had to manually declare C and C++ functions. I don't see how that's different from pretty much any other language that can call C (i.e. pretty much all of them). Then there's preprocessor macros.
I don't know how Zig does it, I'd have to look.
I expand on why dpp is the way it is in my DConf 2019 talk: https://www.youtube.com/watch?v=79COPHF3TnE&t=8s
Nim has an automated generator for C/C++ wrappers or translating from C.
Also there are very easy ways to create Python modules in Nim:
https://robert-mcdermott.gitlab.io/posts/speeding-up-python-...
https://github.com/yglukhov/nimpy
Thanks for the links.
That's nice, but not the same - users have to intend to write a Python extension in Nim. With autowrap, you can call unmodified D code (and as shown in the blog, C code as well with dpp). That means code that was never meant for consumption from another language can be made available.
You don't need to modify the code, just add a wrapper.
Nothing prevents generating a wrapper automatically but 99% of the time that is not very useful. The large majority of Python extension contain Python-specific code to access or return Python objects or act in a pythonic way.
Still not the same.
Except, and I cannot stress this enough, at work we're using this to succesfully call into D production code without any Python-specific anything. It just works. The article wasn't even about that, it's about making it work just as seamlessly for C.
Zig basically includes clang inside of it: https://twitter.com/andy_kelley/status/1099485306783440896
It's easy to call preprocessor macros from Nim, no difference from wrapping C:
Example on wrapping a simple benchmark macro:
- https://github.com/mratsim/weave/blob/052ae40a/experiments/e...
- https://github.com/mratsim/weave/blob/052ae40a/experiments/e...
While nice, one still has to manually declare a Nim proc and tell it whence it came from. That's not the same.
...or let automated tools like c2nim do the job.
So just like the article describes.