This page is part of the web mail archives of SRFI 50 from before July 7th, 2015. The new archives for SRFI 50 contain all messages, not just those from before July 7th, 2015.
The draft quite sanely protects C code from always having to cope with
multiple returns (not to mention state-saving) as via upward
continuations. C code should not, however, be _prevented_ from
constructing an upwards continuation.
The draft is silent on tail call optimization which is an unfortuante
omission that limits, for example, the kinds of higher-order
procedures that can be implemented using the FFI.
It's silent about asynchronous interrupts which, while not standard
Scheme, are likely to be an important feature of most
implementations. In an interactive application especially, absense of
support for asynchronous interruption in "built-in" procedures can
spoil an application's usability.
It uses non-local exits for errors which raises the unwind-protection
issues I mentioned earlier.
I would therefore like to suggest the draft be revised on four
points:
1) Don't use non-local exits for errors. Instead, provide a
mechanism for returning error codes. If Scheme return values are
to be passed via output parameters, then there is a convenient
interface for this:
error_code = SCHEME_CAR (&return_value, instance, &pair);
if (error_code)
{
/* clean up and return an error to our caller */
return error_code;
}
/* otherwise, continue normally. The call to CAR
* succeeded.
*/
In addition to avoiding non-local exits in the FFI, this style of
error handling is closer to what is customary in C.
2) Do provide polling for asynchronous interruption.
As in:
while (very_long_loop)
{
...
if (SCHEME_INTERRUPT_POLL (instance))
{
/* cleanup and return early */
return SCHEME_ERR_INTERRUPT;
}
...
}
3) Do provide a "trampoline-on-the-ceiling" style of tail calls for C.
As in:
scheme_error_code
fn ( [...] )
{
[...];
/* instead of returning a value, something vaguley like:
*/
SCHEME_CONSTRUCT_APPLICATION (&result, instance, &proc,
&arg1, &arg2, ...);
return SCHEME_ERR_MAKE_TAILCALL;
}
in which case my caller is responsible for performing the procedure
application I constructed.
While certainly not as fast as what an implementation can do
internally, such tail calls are at least safe-for-space and
portable.
The converse of that is that the FFI needs to specify how to
call a function which might request the caller to complete a
tail call.
4) Do provide upward continuations from C.
I don't have an interface sketch but, briefly, while the
current interfaces for call-outs are fine, it should also
be possible to write a C primitive that accepts as input a
first-class representation of its continuation and returns
the same.
Used in a manner similar to the mechanism shown above for
tail calls, this can permit FFI-using primitives whose
state can be captured in an upward continuation.
-t