On Wed, 24 Dec 2003, Tom Lord wrote:

>
>I'm imagining cases like scientists wanting to bind a scientific
>numeric libray without being overly tied to a given scheme.  The
>latencies of a compute-server approach would be killers.

Very true.  Math, IMO, is something that any worthwhile scheme has
to handle, and handle well, natively.  I don't think any general
FFI can be so low-overhead that it will be feasible to use it for
performance-intensive mathematics.

>
>On the topic of "radical approaches" and in the opposite direction:
>
>My handwavy conceptual view of things is in terms of a vague "design
>space of Scheme implementations".
>
>There's a bunch of huge trade-offs you can make (e.g., object
>representations; GC strategies).
>
>A truly "portable FFI" has to be agnostic about all of those
>trade-offs and thus, necessarily, is limited in what it can do
>efficiently.
>
>I hypothesize a "non-portable FFI", largely a superset of the perfect
>portable FFI, not limited in what it can do efficiently, which _does_
>constrain implementations but, nevertheless, doesn't constrain them in
>ways that really matter much.  But that's too big for a SRFI.

If you can make useful statements about such a thing it seems to
me that you must have profound insights into the "design space" of
implementations.  I don't see that deeply into it; as far as I can
tell there are fundamental and irreconcilable differences between
the way different implementors do what they do.

				Bear