3 ms·

Wait, what are you people expecting from the C API? Do you not realize literally every other scripting language integration faces this exact design? At the end

Wait, what are you people expecting from the C API? Do you not realize literally every other scripting language integration faces this exact design? At the end of the day, you will always need to take values, plug them into a function, and return that value back to to the VM if desired. Lua, Ruby, V8, you name it, they all do it. Are you expecting to magically pass a function and have some metaprogramming do everything for you? I mean this was certainly possible with LuaBind but then you suddenly take on Boost, and any experienced integrator will realize some systems quickly need more control than this.

to3m 11y ago
Yes, exactly: you have to write little shim functions. I'm pretty sure this was what bdamm was complaining about, and I'm complaining about it too. I took your suggestion to be that there was some way of using the API that avoided this. There might be no better way of doing it (or maybe there might be - I have no opinion), but that wouldn't in my view automatically make the C API "remarkably excellent", "absolutely painless", nor the sort of thing that you might describe as "as easy as it is" (as were the original claims). It would just make it no more inconvenient than it has to be. Forgive me for not getting overly excited at that ;)
pathsjs 11y ago
For instance, interfacing with c in factor works like this. You have an internal dsl that allows you to express what the signature of a c function is. It is designed to look like a function declaration in c, but it is actually valid factor. And... that's it! You can now call that function, and some meta programming drives from that pseudo signature all the information to translate values back and forth
- sitkack 11y ago
  LuaJIT has http://luajit.org/ext_ffi.html http://luajit.org/ext_ffi.html and Python has https://cffi.readthedocs.org/en/latest/ https://cffi.readthedocs.org/en/latest/ modeled after LuaJIT. The API for Lua is very clean for being magic free, something that cannot be said for the CPython API.

to3m 11y ago

Yes, exactly: you have to write little shim functions. I'm pretty sure this was what bdamm was complaining about, and I'm complaining about it too. I took your suggestion to be that there was some way of using the API that avoided this. There might be no better way of doing it (or maybe there might be - I have no opinion), but that wouldn't in my view automatically make the C API "remarkably excellent", "absolutely painless", nor the sort of thing that you might describe as "as easy as it is" (as were the original claims). It would just make it no more inconvenient than it has to be. Forgive me for not getting overly excited at that ;)

pathsjs 11y ago

For instance, interfacing with c in factor works like this. You have an internal dsl that allows you to express what the signature of a c function is. It is designed to look like a function declaration in c, but it is actually valid factor. And... that's it! You can now call that function, and some meta programming drives from that pseudo signature all the information to translate values back and forth

sitkack 11y ago
LuaJIT has http://luajit.org/ext_ffi.html http://luajit.org/ext_ffi.html and Python has https://cffi.readthedocs.org/en/latest/ https://cffi.readthedocs.org/en/latest/ modeled after LuaJIT. The API for Lua is very clean for being magic free, something that cannot be said for the CPython API.