On Wed, Nov 16, 2011 at 4:41 AM, Ray Dillinger <[email protected]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/15/2011 07:17 PM, Grant Rettke wrote: > > Hi, > > > > Based on discussions on the wiki it seems that FFI is clearly out of > > scope of the standard because everyone does it differently. That said, > > it is important enough to be discussed in the first place. > > > > Is the role of the standard simply to recognize it's importance and > > rationale for not finding a common api? Or is the lack of a common api > > simply a reflection of the fact that there is not one? > > The problem is not simply that "everyone does it differently." > The problem is that insofar as implementations are different > and the environments upon which they are hosted are different, > there is no possible way for "everyone" to do FFI the same > way. > > 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. > I doubt there would be any harm in having two supplemental specifications, supported by SRFI-0/7 work-alike, to support the JVM & C as FFI targets (and potentially .Net). This would cover the overwhelming majority of user's needs, and would be a great boost to Scheme's ability to interact with systems in a standardized way (like ctypes for python or C/UFFI for CL). > 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. > I would think that the standard would define something akin to Bordeaux threads and support some minimal-level of threading across a wide variety of systems, whilst the language itself would allow for users to select the best possible threading for themselves via SRFI-0/7. It could be as simple as falling back to continuation based threads should the OS/VM target not support threading natively. > > It is not sensible to suppose that a system which represents > strings as Tries of UTF-16 character buffers ought to do FFI > regarding strings in the same way as a system that stores > strings as arrays of UTF-8 characters. > A decent FFI would allow the user to work around this. I don't think having a standard FFI means assuming that there is no difference in ABI, system calls, &c., but it would mean that if I need to interact with C on system X, I don't have different syntax from system Y, even though the way I interact with system X is *completely* different from system Y (32 vs 64 bit, ropes vs flat strings, ad infinitum). There are different issues with writing C on different platforms, that doesn't mean we have a new spec for each (although the C spec leaves much to be desired); I can still describe structures with the same syntax, and deal with each platform's particulars in platform-specific code. I don't see why I wouldn't do the same with some idealized Scheme FFI. > > 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). > I'm not sure I get the point here, and it almost seems like a red-herring, since it has nothing to do with supporting C/Java/Fortran/whatever interfacing. > > and so on. > I could see it argued that this is outside the "small language" requirements of WG1, but not for the dismissive reasoning above. > > Bear > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJOw4VJAAoJEAOzWkqOibfNKfgH/3jI6qZoUT8HrvhYu97hJviR > smUEdmW8NKf7s6t6675NjFHPXmw+/WczFhj6R+p8kqpGbsuaL8LK7kf6YIw88HLl > wI0oZwBL6Iy1Ceq8v8pDTYL17zhtCxSVoGYqEG8NbV4IH1iHEP57oTMqr7XswWUt > ST4N0H0rQY2kL2ovBv1amO7VFWKGxNpjxXyYxwSXGv0pMqXGz/WVl44zluZ5kpjG > CjeSxp9nMOElH7Oe1g3ZRYhtMkM44+cCPq0+L4tu8Loj8TvWl2fgWJl+sjKxfL+6 > kIlhhFDIINQ+wwY8JaYehWExdLjU27xvF7eX5uly2DfzARVDwAtv9RdUTTQ9nfM= > =r92w > -----END PGP SIGNATURE----- > > _______________________________________________ > Scheme-reports mailing list > [email protected] > http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports > -- ==== Q. How many Prolog programmers does it take to change a lightbulb? A. No.
_______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
