On Thu, 2013-02-14 at 18:21 +1100, William ML Leslie wrote:
> On 13 February 2013 05:24, Mark H Weaver wrote:
> > Okay, but here I'm using "Static FFI" to mean something very different
> > than the C API: I'm talking about a pure scheme-based API that would be
> > quite similar to the API our curr
On 13 February 2013 05:24, Mark H Weaver wrote:
> Okay, but here I'm using "Static FFI" to mean something very different
> than the C API: I'm talking about a pure scheme-based API that would be
> quite similar to the API our current dynamic FFI, except that a lot of
> the work would be done at co
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver skribis:
>>
>>> 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 str
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> 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 d
Mark H Weaver 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
