Re: Dynamic FFI vs Static FFI (was Re: About Guile crypto support)

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> It seems to me that the dynamic FFI performs, at run time, the same jobs
> that a C compiler performs at compile time.  If at some point we add
> support for accessing preprocessor macros and type definitions (which
> seems important), then we'll need the header files as well.  So it makes
> sense to me that a full-featured dynamic FFI fundamentally depends on
> information that's only available in the *-dev packages.

I don’t think you would parse header files at run-time.  I’d rather do
this at macro expansion time.

Overall, I think it’s good to pay attention to what popular distros do,
while at the same time keeping in mind that we’re not bound by their
policies, and could very well come up with use cases that are hindered
by these policies.

> At some point, it might make sense to create a more static FFI that
> works more like a C compiler does, splitting the job into compile-time
> and run-time phases.  This static FFI would be strictly less powerful
> than the dynamic FFI, in a similar sense to how syntactic record APIs
> are less powerful than procedural ones.  However, the static FFI would
> be sufficient in most cases, and would have some advantages.

In my mind the “static FFI” is the C API, and the dynamic FFI is
(system foreign).

To me, the main advantage of the latter is its simplicity of use and
deployment.

Thanks,
Ludo’.