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.
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