> From: Michael Sperber <xxxxxx@informatik.uni-tuebingen.de>

    > Tom> What is this "lots of code"?   Can we identify and quantify it?

    > Off the top of my head, from my most immediate environment:

My impression has changed now: formerly I would have said that
Pika-style has the disadvantage that no existing Scheme system uses
it.  (That's rapidly changing, btw.)  Now I would say we are on a
level playing field in that regard.

    > - most of scsh
    > - bindings for ODBC (also for scsh)
    > - bindings for NIS and LDAP (also for scsh)

I'd appreciate it if you could say more about this: quantities of
code, filenames and distributions containing them, and what you think
the effort of migration from native-scsh to draft-ffi would involve.

I sampled some of the C code in a version of SCSH that I have on hand
(0.5.2 -- sorry, a download for a more recent version was taking _way_
too long so I'll risk being embarassed that everything has changed
since then).

I found a fair amount of C that appears to be automatically generated
-- am I right to presume that porting autogenerated code to _any_ FFI
should not be that hard?

I looked at re1.c (the function `re_search') and found a function
that, modulo alpha-renaming some entry points, looks like it would
compile under some implementations of the draft FFI -- but also looks
to me like it would be _incorrect_ under the draft FFI.  It fails to
protect arguments, treats STRING_REF() as an lvalue, assumes that
VECTOR_LENGTH returns an int, fails if an rm_so or rm_eo field does
not fit in a fixnum, treats VECTOR_REF() as an lvalue, compares a
value to #f using C's != operator, and leaks the `regmatch_t *' memory
allocated for `pm' upon error (such as an incorrectly sized start_vec
argument) --- basically, it would need to be completely rewritten.  Is
it all like that?

Then I looked at syscalls1.c and saw the same sorts of problems.  It
would again need little less than a complete rewrite.

(Incidentally, the draft's *_LENGTH routines would probably be
improved by returning size_t or ssize_t rather than long.)

    > - the bindings which come with Elk (I believe that includes Xlib, Xt,
    >   and Motif, among other assorted stuff)

I haven't examined that but having looked at some SCSH code I'm really
skeptical that this stuff will port easilly to the draft FFI just
because you think the interfaces are similar.

    > I don't know how close the stuff written for PLT 3m is, and how much
    > there is of it.

I don't think that that stuff counts -- is the PLT documentation out
of date or does that code rely on conservative GC.

    > I also suspect that some stuff written for O'Caml (which also has a
    > SRFI-50-style FFI) could be adapted pretty easily.  I don't have a
    > list handy, but there's quite a lot of stuff there.

I'm most skeptical about that.  You're talking about comparing the
cost of converting that code from "O'Caml FFI and O'Caml types" to
Pika-style or draft-50-style Scheme FFI.  Where the two FFI styles
differ it is mostly over matters where the types between the two
languages also differ.  I'd expect the type issues to dominate the
costs.  (This is not to even get into the question of whether the FFI
has enough primitives to port any of that code.)

-t