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: cowan@ccil.org]
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
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports