When you're writing Scheme code in CHICKEN it's sometimes necessary to make a little excursion to C. For example, you're trying to call a C library, you're writing extremely performance-critical code, or you're working on something that's best expressed in C, such as code that requires a lot of bit-twiddling.

This post contains a lot of code, including generated C code. If you get too tired to absorb it, it's probably best to stop reading and pick it up again later.

A basic example of invoking C code from CHICKEN

This is one of CHICKEN's strengths: the ability to quickly drop down to C for a small bit of code, and return its result to Scheme:

( import foreign ) ( define ilen ( foreign-lambda* long ( ( unsigned-long x ) ) "unsigned long y;

" "long n = 0;

" "#ifdef C_SIXTY_FOUR

" "y = x >> 32; if (y != 0) { n += 32; x = y; }

" "#endif

" "y = x >> 16; if (y != 0) { n += 16; x = y; }

" "y = x >> 8; if (y != 0) { n += 8; x = y; }

" "y = x >> 4; if (y != 0) { n += 4; x = y; }

" "y = x >> 2; if (y != 0) { n += 2; x = y; }

" "y = x >> 1; if (y != 0) C_return(n + 2);

" "C_return(n + x);" ) ) ( print "Please enter a number" ) ( print "The length of your integer in bits is " ( ilen ( read ) ) )

This example is taken from a wonderful little book called "Hacker's Delight", by Henry S. Warren. It calculates the number of bits required to represent an unsigned integer (its "length"). By the way, this procedure is provided by the numbers egg as integer-length . The algorithm is implementable in Scheme, but at least a direct translation to Scheme is nowhere as readable as it is in C:

( define ( ilen x ) ( let ( ( y 0 ) ( n 0 ) ) ( cond-expand ( 64bit ( set! y ( arithmetic-shift x -32 ) ) ( unless ( zero? y ) ( set! n ( + n 32 ) ) ( set! x y ) ) ) ( else ) ) ( set! y ( arithmetic-shift x -16 ) ) ( unless ( zero? y ) ( set! n ( + n 16 ) ) ( set! x y ) ) ( set! y ( arithmetic-shift x -8 ) ) ( unless ( zero? y ) ( set! n ( + n 8 ) ) ( set! x y ) ) ( set! y ( arithmetic-shift x -4 ) ) ( unless ( zero? y ) ( set! n ( + n 4 ) ) ( set! x y ) ) ( set! y ( arithmetic-shift x -2 ) ) ( unless ( zero? y ) ( set! n ( + n 2 ) ) ( set! x y ) ) ( set! y ( arithmetic-shift x -1 ) ) ( if ( not ( zero? y ) ) ( + n 2 ) ( + n x ) ) ) )

The performance of the Scheme version is also going to be less than that of the C version. All in all, plenty of good reasons to prefer integration with C. There's no shame in that: most fast languages forego "pure" implementations in favour of C for performance reasons. The only difference is that calling C in other languages is often a bit more work.

Analysing the generated code

In this section we'll unveil the internal magic which makes C so easily integrated with Scheme. You can skip this section if you aren't interested in low-level details.

As you might have noticed, the C code in the example above contains one unfamiliar construct: It uses C_return() to return the result. If you inspect the code generated by CHICKEN after compiling it via csc -k test.scm , you'll see that it inserts some magic to convert the C number to a Scheme object. I've added some annotations and indented for readability:

#define return(x) \ C_cblock C_r = ( C_long_to_num ( &C_a, ( x ) ) ) ; goto C_ret; C_cblockend static C_word C_fcall stub7 ( C_word C_buf, C_word C_a0 ) C_regparm; C_regparm static C_word C_fcall stub7 ( C_word C_buf, C_word C_a0 ) { C_word C_r = C_SCHEME_UNDEFINED, *C_a= ( C_word* ) C_buf; unsigned long x = ( unsigned long ) C_num_to_unsigned_long ( C_a0 ) ; unsigned long y; long n = 0; #ifdef C_SIXTY_FOUR y = x >> 32; if ( y != 0 ) { n += 32; x = y; } #endif y = x >> 16; if ( y != 0 ) { n += 16; x = y; } y = x >> 8; if ( y != 0 ) { n += 8; x = y; } y = x >> 4; if ( y != 0 ) { n += 4; x = y; } y = x >> 2; if ( y != 0 ) { n += 2; x = y; } y = x >> 1; if ( y != 0 ) C_return ( n + 2 ) ; C_return ( n + x ) ; C_ret: #undef return return C_r; } #define C_return(x) return(x) #define C_cblock do{ #define C_cblockend }while(0)

In the foreign-lambda* , I used C_return for clarity: I could have just used return with parentheses, which will get expanded by the C preprocessor. This is somewhat confusing: return n + x; will result in an error, whereas return(n+x); will do the same as C_return(n+x); .

The return macro calls C_long_to_num , which will construct a Scheme object, which is either a fixnum (small exact integer) or a flonum (floating-point inexact number), depending on the platform and the size of the returned value. Hopefully, in CHICKEN 5 it will be either a fixnum or a bignum - that way, it'll always be an exact integer.

Because these number objects need to get allocated on the stack to integrate with the garbage collector, the calling code needs to set aside enough memory on the stack to fit these objects. That's what the C_buf argument is for: it's a pointer to this area. In CHICKEN, a whole lot of type punning is going on, so it's passed as a regular C_word rather than as a proper pointer, but let's ignore that for now.

The stub function above is used to do the actual work, but in order to integrate it into CHICKEN's calling conventions and garbage collector, an additional wrapper function is generated. It corresponds to the actual Scheme "ilen" procedure, and looks like this:

static void C_ccall f_201 ( C_word c, C_word t0, C_word t1, C_word t2 ) { C_word tmp ; C_word t3; C_word t4; C_word t5; C_word ab [ 6 ] , *a=ab; if ( c != 3 ) C_bad_argc_2 ( c, 3, t0 ) ; C_check_for_interrupt; if ( !C_stack_probe ( &a ) ) { C_save_and_reclaim ( ( void * ) tr3, ( void * ) f_201, 3, t0, t1, t2 ) ; } t3 = C_a_i_bytevector ( &a,1,C_fix ( 4 ) ) ; t4 = C_i_foreign_unsigned_integer_argumentp ( t2 ) ; t5 = t1; ( ( C_proc2 ) ( void * ) ( * ( ( C_word* ) t5+1 ) ) ) ( 2, t5, stub7 ( t3, t4 ) ) ; }

The comment at the top indicates the name of the Scheme procedure and its location in the CPS-converted Scheme code. The k197 in k194 etc indicate the nesting in the generated continuations, which can sometimes be useful for debugging. These continuations can be seen in the CPS-converted code by compiling with csc -debug 3 test.scm .

Much of the code you might sort-of recognise from the code in my article about the CHICKEN garbage collector: The C_stack_probe() corresponds to that post's fits_on_stack() , and C_save_and_reclaim() combines that post's SCM_save_call() and SCM_minor_GC() .

All Scheme procedures get compiled down to C functions which receive their argument count ( c ), the closure/continuation from which they're invoked ( t0 ), so they can access local closure variables (not used here) and in order to perform a GC and re-invoke the closure. Finally, they receive the continuation of the call ( t1 ) and any procedure arguments (everything after it, here only t2 ). If a procedure has a variable number of arguments, that will use C's varargs mechanism, which is why passing the argument count to every function is important. If a function is called with too many or too few arguments, this will "just work", even if the arguments are declared in the function prototype like here: The function is invoked correctly, but the stack will contain rubbish instead of the expected arguments. That's why it's important to first check the argument count, and then check whether a GC needs to be performed; otherwise, this rubbish gets saved by save_and_reclaim and the GC will attempt to traverse it as if it contained proper Scheme objects, resulting in segfaults or other nasty business.

The variable t3 will contain the buffer in which the return type is stored. It is wrapped in a byte vector, because this makes it a first-class object understood by the garbage collector. That's not necessary here, but this code is pretty generic and is also used in cases where it is necessary. The C_word ab[6] declaration sets aside enough memory space to hold a flonum or a fixnum, which need at most 4 bytes, plus 2 bytes for the bytevector wrapper. I will explain these details later in a separate post, but let's assume it's OK for now.

The argument type gets checked just before calling the C function. If the argument is not of the correct type, an error is signalled and the function will be aborted. The returned value is simply the input, so t4 will contain the same value as t2 . Similarly, t1 gets copied as-is to t5 . Finally, the continuation gets cast to the correct procedure type (again: a lot of type punning. I will explain this in another post), and invoked with the correct argument count (2), the continuation closure itself, and the return value of the stub function.

Returning complex Scheme objects from C

I've tried to explain above how the basic C types get converted to Scheme objects, but what if we want to get crazy and allocate Scheme objects in C? A simple foreign-lambda* won't suffice, because the compiler has no way of knowing how large a buffer to allocate, and the C function will return, so we'll lose what's on the stack.

To fix that, we have foreign-safe-lambda* , which will allow us to allocate any object on the stack. Before such a function is invoked, a minor garbage collection is triggered to clean the stack and ensure we have plenty of allocation room. Let's look at a simple example. This program displays the list of available network interfaces on a UNIX-like system:

( import foreign ) ( foreign-declare "#include \" sys/types.h \" " ) ( foreign-declare "#include \" sys/socket.h \" " ) ( foreign-declare "#include \" ifaddrs.h \" " ) ( define interfaces ( foreign-safe-lambda* scheme-object ( ) "C_word lst = C_SCHEME_END_OF_LIST, len, str, *a;

" "struct ifaddrs *ifa, *i;

" "

" "if (getifaddrs(&ifa) != 0)

" " C_return(C_SCHEME_FALSE);

" "

" "for (i = ifa; i != NULL; i = i->ifa_next) {

" " len = strlen(i->ifa_name);

" " a = C_alloc(C_SIZEOF_PAIR + C_SIZEOF_STRING(len));

" " str = C_string(&a, len, i->ifa_name);

" " lst = C_a_pair(&a, str, lst);

" "}

" "

" "freeifaddrs(ifa);

" "C_return(lst);

" ) ) ( print "The following interfaces are available: " ( interfaces ) )

This functionality is not available in CHICKEN because it's not very portable (it's not in POSIX), so it's a good example of something you might want to use C for. Please excuse the unSchemely way of error handling by returning #f for now. We'll fix that in the next chapter.

Looking at our definition, the interfaces procedure has no arguments, and it returns a scheme-object . This type indicates to CHICKEN that the returned value is not to be converted but simply used as-is: we'll handle its creation ourselves.

We declare the return value lst , which gets initialised to the empty list, and two temporary variables: len and str , to keep an intermediate string length and to hold the actual CHICKEN string. The variable a is an allocation pointer. Then we have the two variables which hold the start of the linked list of interfaces, ifa , and the current iterator through this list, i .

We retrieve the linked list (if it fails, returning #f ), and scan through it until we hit the end. For each entry, we simply check the length of the interface name string, we allocate enough room on the stack to hold a pair and a CHICKEN string of the same length ( C_alloc() is really just alloca() ). The C_SIZEOF... macros are very convenient to help us calculate the size of an object without having to know its exact representation in memory. We then create the CHICKEN string using C_string , which is put into the allocated space stored in a , and we create a pair which holds the string in the car and the previous list as its cdr .

These allocating C_a_pair and C_string functions accept a pointer to the allocated space (which itself is a pointer). This means they can advance the pointer's value beyond the object, to the next free position. This is quite nice, because it allows us to call several allocating functions in a row, with the same pointer, and at the end the pointer points past the object that was allocated last. Finally, we release the memory used by the linked list and return the constructed list.

Analysing the generated code

Like before, if you're not interested in the details, feel free to skip this section.

The interfaces foreign code itself compiles down to this function:

#define return(x) C_cblock C_r = (((C_word)(x))); goto C_ret; C_cblockend static void C_ccall stub6 ( C_word C_c, C_word C_self, C_word C_k, C_word C_buf ) C_noret; static void C_ccall stub6 ( C_word C_c, C_word C_self, C_word C_k, C_word C_buf ) { C_word C_r = C_SCHEME_UNDEFINED, *C_a = ( C_word * ) C_buf; int C_level = C_save_callback_continuation ( &C_a, C_k ) ; struct ifaddrs *ifa, *i; C_word lst = C_SCHEME_END_OF_LIST, len, str, *a; if ( getifaddrs ( &ifa ) != 0 ) C_return ( C_SCHEME_FALSE ) ; for ( i = ifa; i != NULL; i = i->ifa_next ) { len = strlen ( i->ifa_name ) ; a = C_alloc ( C_SIZEOF_PAIR + C_SIZEOF_STRING ( len ) ) ; str = C_string ( &a, len, i->ifa_name ) ; lst = C_a_pair ( &a, str, lst ) ; } freeifaddrs ( ifa ) ; C_return ( lst ) ; C_ret: #undef return C_k = C_restore_callback_continuation2 ( C_level ) ; C_kontinue ( C_k, C_r ) ; }

This is not much different from the foreign-lambda* example, but notice that the arguments are different: this stub looks exactly like the C code generated from an actual Scheme continuation: it gets passed the argument count, its own closure and its continuation. Instead of ending with a regular return from C, it invokes a continuation. This is the crucial difference which integrates our code with the garbage collector: by passing it to the next continuation's C function, the "returned" value is preserved on the stack. In other words, it is allocated directly in the nursery.

Even though the stub is a "native" Scheme procedure, a wrapper is still generated: if the foreign-safe-lambda is defined to accept C arguments, it'll still need to convert from Scheme objects, it needs to check the argument count, and it needs to invoke the GC before the procedure can be called:

static void C_ccall f_201 ( C_word c, C_word t0, C_word t1 ) { C_word tmp; C_word t2; C_word t3; C_word ab [ 3 ] , *a = ab; if ( c!=2 ) C_bad_argc_2 ( c, 2, t0 ) ; C_check_for_interrupt; if ( !C_stack_probe ( &a ) ) { C_save_and_reclaim ( ( void * ) tr2, ( void * ) f_201,2,t0,t1 ) ; } t2 = ( *a = C_CLOSURE_TYPE|2, a [ 1 ] = ( C_word ) f_205, a [ 2 ] = t1, tmp = ( C_word ) a, a += 3, tmp ) ; C_trace ( "test.scm:8: ##sys#gc" ) ; ( ( C_proc3 ) C_fast_retrieve_symbol_proc ( lf [ 1 ] ) ) ( 3, * ( ( C_word* ) lf [ 1 ] +1 ) , t2, C_SCHEME_FALSE ) ; } static void C_ccall f_205 ( C_word c, C_word t0, C_word t1 ) { C_word tmp; C_word t2; C_word t3; C_word t4; C_word ab [ 8 ] , *a=ab; C_check_for_interrupt; if ( !C_stack_probe ( &a ) ) { C_save_and_reclaim ( ( void * ) tr2, ( void * ) f_205, 2, t0, t1 ) ; } t2 = C_a_i_bytevector ( &a, 1, C_fix ( 3 ) ) ; t3 = ( *a = C_CLOSURE_TYPE|2, a [ 1 ] = ( C_word ) stub6, a [ 2 ] = ( ( C_word ) li0 ) , tmp = ( C_word ) a, a += 3, tmp ) ; C_trace ( "test.scm:8: g9" ) ; t4 = t3; ( ( C_proc3 ) C_fast_retrieve_proc ( t4 ) ) ( 3, t4, ( ( C_word* ) t0 ) [ 2 ] , t2 ) ; }

Our foreign-lambda's wrapper function now consists of two stages. The first stage first creates a continuation for the usual wrapper function. Then it calls the garbage collector to clear the stack, after which this wrapper-continuation is invoked. This wrapper is the second function here, and it corresponds closely to the wrapper function we saw in the ilen example. However, this wrapper constructs a closure around the C stub function instead of simply calling it. This closure is then called: C_fast_retrieve_proc simply extracts the function from the closure object we just created, it is cast to a 3-argument procedure type and invoked with the continuation of the interfaces call site.

You can see how closures are created in CHICKEN. I will explain this in depth in a future blog post, but the basic approach is pretty clever: the whole thing is one big C expression which stores successive words at the free slots in the allocated space a , while ensuring that after the expression a will point at the next free word. The dance with tmp ensures that the whole expression which allocates the closure results in the initial value of a . That initial value was the first free slot before we executed the expression, and afterwards it holds the closure. Don't worry if this confuses you :)

Calling Scheme from C

Now, with the basics out of the way, let's do something funkier: instead of calling C from Scheme, we call Scheme from C! There is a C API for embedding CHICKEN in a larger C program, but that's not what you should use when calling Scheme from C code that was itself called from Scheme.

The "easy" way

Our little interfaces-listing program has one theoretical flaw: the list of interfaces could be very long (or the names could be long), so we may theoretically run out of stack space. So, we should avoid allocating unbounded lists directly on the stack without checking for overflow. Instead, let's pass the allocated objects to a callback procedure which prints the interface, in a "streaming" fashion.

As I explained before, a regular foreign-lambda uses the C stack in the regular way, it doesn't know about continuations or the Cheney on the MTA garbage collection style, and there's no way to call CHICKEN functions from there, because the GC would "collect" away the C function by longjmp() ing past it. However, the foreign-safe-lambda has a special provision for that: it can "lock" the current live data by putting a barrier between this C function and the Scheme code it calls:

( import foreign ) ( foreign-declare "#include \" sys/types.h \" " ) ( foreign-declare "#include \" sys/socket.h \" " ) ( foreign-declare "#include \" ifaddrs.h \" " ) ( define interfaces ( foreign-safe-lambda* scheme-object ( ( scheme-object receiver ) ) "C_word len, str, *a;

" "struct ifaddrs *ifa, *i;

" "

" "if (getifaddrs(&ifa) != 0)

" " C_return(C_SCHEME_UNDEFINED);

" "

" "for (i = ifa; i != NULL; i = i->ifa_next) {

" " len = strlen(i->ifa_name);

" " a = C_alloc(C_SIZEOF_STRING(len));

" " str = C_string(&a, len, i->ifa_name);

" " C_save(str);

" " C_callback(receiver, 1);

" "}

" "

" "freeifaddrs(ifa);

" "C_return(C_SCHEME_UNDEFINED);

" ) ) ( print "The following interfaces are available: " ) ( interfaces print )

This will display the interfaces one line at a time, by using CHICKEN's print procedure as the callback.

We won't look at the compiled source code for this implementation, because it is identical to the earlier one, except for the changed foreign-lambda body. The implementation of C_callback() is of interest, but it is a little hairy, so I'll leave it you to explore it yourself.

The basic idea is rather simple, though: it simply calls setjmp() to establish a new garbage collection trampoline. This means that the foreign-lambda will always remain on the stack. The callback is then invoked with a continuation which sets a flag to indicate that the callback has returned normally, in which case its result will be returned to the foreign-lambda. If it didn't return normally, we arrived at the trampoline because a GC was triggered. This means the remembered continuation will be re-invoked, like usual.

However, when the callback did return normally, we can simply return the returned value because the foreign-lambda's stack frame is still available due to the GC barrier we set up.

The C_save macro simply saves the callback's arguments on a special stack which is read by C_do_apply . It is also used by callback_return_continuation : it saves the value and triggers a GC to force the returned value into the heap. That way, we can return it safely to the previous stack frame without it getting clobbered by the next allocation.

A harder way

The above code has another flaw: if the callback raises an exception, the current exception handler will be invoked with the continuation where it was established. However, that might never return to the callback, which means we have a memory leak on our hands!

If the callback doesn't return normally, the foreign-lambda will remain on the stack forever. How do we avoid that little problem? The simplest is of course to wrap the callback's code in handle-exceptions or condition-case . However, that's no fun at all.

Besides, in real-world code we want to avoid the overhead of a GC every single time we invoke a C function, so foreign-safe-lambda is not really suitable for functions that are called in a tight loop. In such cases, there is only one way: to deeply integrate in CHICKEN and write a completely native procedure! Because truly native procedures must call a continuation when they want to pass a result somewhere, we'll have to chop up the functionality into three procedures:

( import foreign ) ( use lolevel ) ( foreign-declare "#include \" sys/types.h \" " ) ( foreign-declare "#include \" sys/socket.h \" " ) ( foreign-declare "#include \" ifaddrs.h \" " ) ( define grab-ifa! ( foreign-lambda* void ( ( ( c-pointer ( c-pointer "struct ifaddrs" ) ) ifa ) ) "if (getifaddrs(ifa) != 0)

" " *ifa = NULL;

" ) ) ( define free-ifa! ( foreign-lambda* void ( ( ( c-pointer ( c-pointer "struct ifaddrs" ) ) ifa ) ) "freeifaddrs(*ifa);

" ) ) ( define next-ifa ( foreign-primitive ( ( ( c-pointer ( c-pointer "struct ifaddrs" ) ) ifa ) ) "C_word len, str, *a;

" "

" "if (*ifa) {

" " len = strlen((*ifa)->ifa_name);

" " a = C_alloc(C_SIZEOF_STRING(len));

" " str = C_string(&a, len, (*ifa)->ifa_name);

" " *ifa = (*ifa)->ifa_next;

" " C_kontinue(C_k, str);

" "} else {

" " C_kontinue(C_k, C_SCHEME_FALSE);

" "}" ) ) ( define ( interfaces ) ( let-location ( ( ifa ( c-pointer "struct ifaddrs" ) ) ( i ( c-pointer "struct ifaddrs" ) ) ) ( grab-ifa! ( location ifa ) ) ( unless ifa ( error "Could not allocate ifaddrs" ) ) ( set! i ifa ) ( handle-exceptions exn ( begin ( free-ifa! ( location ifa ) ) ( signal exn ) ) ( let lp ( ( result ' ( ) ) ) ( cond ( ( next-ifa ( location i ) ) => ( lambda ( iface ) ( lp ( cons iface result ) ) ) ) ( else ( free-ifa! ( location ifa ) ) result ) ) ) ) ) ) ( print "The following interfaces are available: " ( interfaces ) )

This compiles to something very similar to the code behind a foreign-safe-lambda , but it's obviously going to be a lot bigger due to it being cut up, so I won't duplicate the C code here. Remember, you can always inspect it yourself with csc -k .

Anyway, this is like the foreign-safe-lambda, but without the implicit GC. Also, instead of "returning" the value through C_return() we explicitly call the continuation C_k through the C_kontinue() macro, with the value we want to pass on to the cond . If we wanted to return two values, we could simply use the C_values() macro instead; we're free to do whatever Scheme can do, so we can even return multiple values, as long as the continuation accepts them.

If an exception happens anywhere in this code, we won't get a memory leak due to the stack being blown up. However, like in any C code, we need to free up the memory behind the interface addresses. So we can't really escape our cleanup duty!

You might think that there's one more problem with foreign-primitive : because it doesn't force a GC before calling the C function, there's still no guarantee about how much space you still have on the stack. Luckily, CHICKEN has a C_STACK_RESERVE , which defines how much space that is guaranteed to be left on the stack after each C_demand() . Its value is currently 0x10000 (i.e., 64 KiB), which means you have some headroom to do basic allocations like we do here, but you shouldn't allocate too many huge objects. There are ways around that, but unfortunately not using the "official" FFI (that I'm aware of, anyway). For now we'll stick with the official Scheme API.

The die-hard way: calling Scheme closures from C

So far, we've discussed pretty much only things you can find in the CHICKEN manual's section on the FFI. Let's take a look at how we can do things a little differently, and instead of passing the string or #f to a continuation, we pass the callback as a procedure again, just like we did for the "easy" way:

( import foreign ) ( use lolevel ) ( foreign-declare "#include \" sys/types.h \" " ) ( foreign-declare "#include \" sys/socket.h \" " ) ( foreign-declare "#include \" ifaddrs.h \" " ) ( define grab-ifa! ( foreign-lambda* void ( ( ( c-pointer ( c-pointer "struct ifaddrs" ) ) ifa ) ) "if (getifaddrs(ifa) != 0)

" " *ifa = NULL;

" ) ) ( define free-ifa! ( foreign-lambda* void ( ( ( c-pointer ( c-pointer "struct ifaddrs" ) ) ifa ) ) "freeifaddrs(*ifa);

" ) ) ( define next-ifa ( foreign-primitive ( ( ( c-pointer ( c-pointer "struct ifaddrs" ) ) ifa ) ( scheme-object more ) ( scheme-object done ) ) "C_word len, str, *a;

" "

" "if (*ifa) {

" " len = strlen((*ifa)->ifa_name);

" " a = C_alloc(C_SIZEOF_STRING(len));

" " str = C_string(&a, len, (*ifa)->ifa_name);

" " *ifa = (*ifa)->ifa_next;

" " ((C_proc3)C_fast_retrieve_proc(more))(3, more, C_k, str);

" "} else {

" " ((C_proc2)C_fast_retrieve_proc(done))(2, done, C_k);

" "}" ) ) ( define ( interfaces ) ( let-location ( ( ifa ( c-pointer "struct ifaddrs" ) ) ( i ( c-pointer "struct ifaddrs" ) ) ) ( grab-ifa! ( location ifa ) ) ( unless ifa ( error "Could not allocate ifaddrs" ) ) ( set! i ifa ) ( handle-exceptions exn ( begin ( free-ifa! ( location ifa ) ) ( signal exn ) ) ( let lp ( ( result ' ( ) ) ) ( next-ifa ( location i ) ( lambda ( iface ) ( lp ( cons iface result ) ) ) ( lambda ( ) ( free-ifa! ( location ifa ) ) result ) ) ) ) ) ) ( print "The following interfaces are available: " ( interfaces ) )

The magic lies in the expression ((C_proc3)C_fast_retrieve_proc(more))(3, more, C_k, str) . We've seen something like it before in generated C code snippets: First, it extracts the C function pointer from the closure object in more . Then, the function pointer is cast to the correct type; C_proc3 refers to a procedure which accepts three arguments. This excludes the argument count, which actually is the first argument in the call. The next argument is the closure itself, which is needed when the closures has local variables it refers to (like result and lp in the example). The argument after the closure is its continuation. We just pass on C_k : the final continuation of both more and done is the continuation of lp , which is also the continuation of next-ifa . Finally, the arguments following the continuation are the values passed as arguments: iface for the more closure.

The done closure is invoked as C_proc2 with only itself and the continuation, but no further arguments. This corresponds to the fact that done is just a thunk.

I've shown two alternative ways to call the closure. The first is to call the closure through the C_do_apply function. This is basically a dispatcher which checks the argument count and uses the correct C_proc<n> cast and then calls it with the arguments, taken from a temporary stack on which C_save places the arguments. The implementation behind it is positively insane, and worth checking out for the sheer madness of it.

The second alternative is to use C_apply , which is the C implementation of Scheme's apply procedure. It's a bit awkward to call from C, because this procedure is a true Scheme procedure. That means it accepts an argument count, itself and its continuation and only then its arguments, which are the closure and the arguments to pass to the closure, with the final argument being a list:

( apply + 1 2 ' ( 3 4 ) ) => 10

In C this would be:

C_apply ( 6, C_SCHEME_UNDEFINED, C_k, C_closure ( &a, 1, C_plus ) , C_fix ( 1 ) , C_fix ( 2 ) , C_list2 ( C_fix ( 3 ) , C_fix ( 4 ) ) ) ;

It also checks its arguments, so if you pass something that's not a list as its final argument, it raises a nice exception:

( import foreign ) ( ( foreign-primitive ( ) "C_word ab[C_SIZEOF_CLOSURE(1)], *a = ab;

" "C_apply(4, C_SCHEME_UNDEFINED, C_k, " " C_closure(&a, 1, (C_word)C_plus), C_fix(1));" ) )

This program prints the following when executed:

Error: (apply) bad argument type: 1 Call history: test.scm:2: g11 <--

And this brings us to our final example, where we go absolutely crazy.

The guru way: Calling Scheme closures you didn't receive

You might have noticed that the error message above appears without us passing the error procedure to + , and if you had wrapped the call in an exception handler it would've called its continuation, without us passing it to the procedure. In some situations you might like to avoid boring the user with passing some procedure to handle some exceptional situation. Let's see if we can do something like that ourselves!

It turns out to be pretty easy:

( import foreign ) ( use lolevel ) ( foreign-declare "#include \" sys/types.h \" " ) ( foreign-declare "#include \" sys/socket.h \" " ) ( foreign-declare "#include \" ifaddrs.h \" " ) ( define grab-ifa! ( foreign-lambda* void ( ( ( c-pointer ( c-pointer "struct ifaddrs" ) ) ifa ) ) "if (getifaddrs(ifa) != 0)

" " *ifa = NULL;

" ) ) ( define free-ifa! ( foreign-lambda* void ( ( ( c-pointer ( c-pointer "struct ifaddrs" ) ) ifa ) ) "freeifaddrs(*ifa);

" ) ) ( define ( show-iface-name x ) ( print x ) #t ) ( define next-ifa ( foreign-primitive ( ( ( c-pointer ( c-pointer "struct ifaddrs" ) ) ifa ) ) "C_word len, str, *a, show_sym, show_proc;

" "

" "if (*ifa) {

" " len = strlen((*ifa)->ifa_name);

" " a = C_alloc(C_SIZEOF_INTERNED_SYMBOL(15) + C_SIZEOF_STRING(len));

" " str = C_string(&a, len, (*ifa)->ifa_name);

" " *ifa = (*ifa)->ifa_next;

" " show_sym = C_intern2(&a, C_text( \" show-iface-name \" ));

" " show_proc = C_block_item(show_sym, 0);

" " ((C_proc3)C_fast_retrieve_proc(show_proc))(3, show_proc, C_k, str);

" "} else {

" " C_kontinue(C_k, C_SCHEME_FALSE);

" "}" ) ) ( define ( interfaces ) ( let-location ( ( ifa ( c-pointer "struct ifaddrs" ) ) ( i ( c-pointer "struct ifaddrs" ) ) ) ( grab-ifa! ( location ifa ) ) ( unless ifa ( error "Could not allocate ifaddrs" ) ) ( set! i ifa ) ( handle-exceptions exn ( begin ( free-ifa! ( location ifa ) ) ( signal exn ) ) ( let lp ( ) ( if ( next-ifa ( location i ) ) ( lp ) ( free-ifa! ( location ifa ) ) ) ) ) ) ) ( print "The following interfaces are available: " ) ( interfaces )

This uses C_intern2 to look up the symbol for "show-iface-name" in the symbol table (or intern it if it didn't exist yet). We store this in show_sym . Then, we look at the symbol's first slot, where the value is stored for the global variable identified by the symbol. The value slot always exists, but if it is undefined, the value is C_SCHEME_UNDEFINED . Anyway, we assume it's defined and we call it like we did in the example before this one: extract the first slot from the closure and call it.