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.
> From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx> > Ray> It's not immediately obvious to me how to implement some of the > Ray> functionality that's not allowed to GC without allocating call > Ray> frames - particularly since strings are represented internally > Ray> as a tree structure. I'll look more closely at it tomorrow and > Ray> cite specific cases. > As to the strings & characters issue---we all agree that it > needs to be addressed. But apart from that? I think "may GC" applies to all entry points. Even something banal like "extract_double" may wind up having to reduce a number by running Scheme code (as in a bignum rational with bignums implemented in Scheme (or just on the Scheme heap) or a continued fraction numeric extension written in Scheme). Other examples of the problem are process migration and persistent stores which are, I think, something that people are likely to take a stab at more often these days. If anything, very simple implementations are one of the more likely places for those kinds of feature to show up. (Why the "constants" should be an exception to "may GC" is something I can't imagine.) I think we've cooked down the implications of some FFI design space parameters to this: Parameter Restricting Resulting Choice Restriction ---------------------------------------------------------------- A. GC only at certain Yes Aynchronous threads may C sequence points? not cause GC; signal handlers may not cause GC B. Scheme values Yes Requires A repesented as C rvalues? C. Barrierless reads Yes Certain incremental GC and writes to Scheme techniques prohibited; locations? Requires A and B Note that (not A) implies (not (or B C)). Coherent choices here are: 1. no to all three 2. A (and B?) (A+B has no disadvantage compared to A?) 3. A, B, and C each progressively more restrictive than the last. (The chart doesn't talk about "human factors" restrictions like tempting users to mistakenly write `cons (a, cons (b, nil))'.) Supposing that your choice is (A+B) or (A+B+C), then there's a new parameter which is what you're asking Ray about: D. Some FFI functions may Yes Scheme types not extensible not cause GC in Scheme; Some scheme types or procedures not implementable in terms of others; (Implies A, of course) which strikes me as eerily Java-esque. Incrementally better in that there is still a _little_ room to "subclass" (for example) the number type or cons-pair type -- but only by a tiny increment since there would still be a huge restriction on representations of (for example) small, exact, integers or pairs. (So much for that big Oaklisp revival?) In all cases, the "resulting restriction" becomes implicit in FFI-using code. An implementation that promises users support for an A+B+C+D FFI in one release can not also promise to add asynchronous execution in an upward compatible way, can not plan to use certain incremental GC techniques while remaining upward compatible with code that uses the FFI, and can not promise to compatibly add extensibility of the basic Scheme types. Does it make sense to request implementation of those restriction in other people's implementations? -t