> From: bear <xxxxxx@sonic.net>

    > 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