On Wed, Nov 16, 2011 at 4:41 AM, Ray Dillinger
<bear@x> 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-----