On Sat, 3 Jan 2004, Michael Sperber wrote:

>>>>>> "felix" == felix  <xxxxxx@call-with-current-continuation.org> writes:
>
>felix> But the problem I see with *this* SRFI is that it specifies too
>felix> much (IMHO). If SRFI-50 is considered a (slightly) portable FFI
>felix> to C, then things could be done considerably simpler, safer and
>felix> completely portable (up to a certain point).  If SRFI-50 is
>felix> only about a semi-standard way of messing with Scheme internals
>felix> at the C level, then I'll keep my mouth shut from now on...
>
>To be honest, you've lost me in a twisty maze of natural-language
>semantics.
>
>*What*?

Well, I can't tell for sure what Felix meant, but if I'd said what
he said I'd have meant this:

    I think that you're striking a rather aggressive balance favoring
    FFI functionality over portability.  While there's nothing wrong
    with that, there's probably room for a simpler SRFI that specifies
    a less general and more portable FFI.  Perhaps that SRFI should
    come before this one.

For the last little while, I've been looking at this SRFI and
realizing that it would be an *AMAZING* amount of work to provide it
in the context of my particular scheme implementation.  But since my
particular implementation isn't something anybody else is using, that
doesn't actually become anyone else's problem.  Still, I probably
would never provide SRFI-50 because it would be too much work and most
of the hardest work would be spent on fiddly bits of functionality
that I'd never use.  Other people have different priorities and talents,
to be sure.  Other scheme systems map in easier and prettier ways to a
C runtime (and have, for example, a C stack that's not sliced into chunks
and allocated in the scheme invocation frames, and work with, eg, the ascii
character set) and could provide it much more easily.  But I'd be looking
for an easier target.

					Bear