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: bear <bear@xxxxxxxxx> > I'm pretty much of the opinion that what gets passed back and > forth across the FFI should be values, not pointers. Let the > C code ask what the value of X is when it wants it, or pass a > value back to store in X. It solves all of these problems, I > think, by making it not-matter when GC happens, keeping C code > out of the structure of the scheme heap, and making it impossible > to run into what-does-it-mean problems with shared structure. We use words in different ways but, through the right lenses, I think I agree with you with one caveat: for the initial portable FFI. The structure-sharing "hair" I was talking about, that you objected to, looks beyond what we'd want in an initial FFI to what we want in extensions to the FFI. Sorry for not making that explicit. For example, the private-copy-of-string-data semantics for string data is simple and clean -- but nearly-necessarily inefficient. Later -- well past an initial FFI SRFI and in the context of new Scheme-independent libraries for C -- I'd want to see some standards for (semantically) shared string data. _Initial_ FFI aside -- it's going to be hard to make a _comprehensive_ FFI for (extended) Scheme without improving the common practices of C programming. What's the value of: (and (not (equal? better worse)) (not (greater-than? better worse)) (not (less-than? better worse)) (on-the-same-pseudo-lattice? better worse) (pseudo-lattice-least-upper-bound better worse) (most-efficient-path-to (pseudo-lattice-least-upper-bound better worse) todays-state)) so to speak. -t