Ray Dillinger scripsit: > It is not sensible to suppose that a system where the operating system > runs on top of a JVM ought to do FFI in a way similar to a system > where the operating system runs on raw hardware.
WG2 balloted three separate packages called "C FFI", "JVM FFI", and "CLR FFI"; I can't see reconciling those into a single package. However, all three were postponed to future WGs. > It is not sensible to suppose that a system where it is possible > to have different threads operating in the same memory arena (such > as Windows or Linux) ought to do FFI in the same way as a "secure" > Operating system in which there is no interprocess communication > except serial communication over ports, such as military OS's based on > the Bell-LaPadula model, etc. That's not so clear to me. A C FFI would tell how to make particular procedure or system calls, not which ones were available. > Nor is it sensible to suppose that in a computer where the OS regards > text as an array of fixed-length strings with an implicit linefeed > between each string (such as some portable devices) FFI ought to be > done in the same way as in a computer where the OS regards text as an > array of characters and a linefeed is just another character (such as > UNIX). The Software Tools effort (Unix command-line utilities in Fortran + C-like preprocessor, for those who don't remember) had an adapter from Fortran's card-oriented I/O to Unix's character model, so there is precedent. -- A poetical purist named Cowan [that's me: [email protected]] Once put the rest of us dowan. [on xml-dev] "Your verse would be sweeter http://www.ccil.org/~cowan If it only had metre And rhymes that didn't force me to frowan." [overpacked line!] --Michael Kay _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
