Easier FFI

[LukeFernandes]

Thanks for Ferret it’s awesome.
The current FFI is non ideal when large C libraries are required. I want to use OpenGL with Ferret. The only solution now AFAIK is to write tedious glue code for every single OpenGL method (and there are loads of little ones).

Compare with Clojure where Java libraries can be consumed trivially e.g. (.glDoSomething 567).

Since Ferret is a new language, why can’t it be designed to lean into the host? Like Clojure leans into the JVM. Why can’t we just use C routines natively, calling them as if they were Lisp functions? If they return pointers or whatever, then why can’t we use the native Ferret C++ pointer type to store them? (EDIT - I’m aware that Ferret has a pointer type. What I would hope for is that it could be created and used easily without inline strings)

[nakkaya]

Luke Hi,

Ferret has no concept of reflection. That's the show stopper for doing things like,

(.glDoSomething 567)

I try to embrace C++ as much as possible but Ferret targets embedded systems and it needs to compile with -fno-rtti which disables reflection. But checking out SWIG [1] is on my list of to-do items. At least the required boiler plate can be generated automatically.

[1] http://www.swig.org/

[chr15m]

@LukeFernandes one possibility to avoid writing tedious glue code is to write macros. You could write a wrapper macro to convert OpenGL calls at compile time.

[bendlas]

checking out SWIG

FWIW, I've had success with generating JNA calls from CastXML [1] output in Clojure.

[1] https://github.com/CastXML/CastXML