Re: when GC is permitted Tom Lord 14 Jan 2004 23:16 UTC
> 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