Brian Rogoff <bpr@shell5.ba.best.com> writes
>This is an often ignored capability for new language designs, the
>ability to cleanly interoperate with old code in other languages.
>I would be very interested in how the functional programming community
>intends to address this, or if it is even considered an important
>problem. I don't think SML has a C FFI (foreign function interface) so
>I'm guessing this was considered too hard or not important enough.
This is a non-trivial problem, mostly because of a fundamental
philosophical clash in storage-management. Since some time in the 1960's
garbage collectors for functional languages have relocated storage blocks
(at Edinburgh we had a version working for Multipop some time before 1970)
And, of course, conventional languages don't expect this to happen. So it's
quite easy to provide call-out from a functional language to, say, C, it is
dangerous if the C-code called out to holds on to a pointer that is passed
in to it. A prime example of course is call-backs for GUI programming.
The Sussex University people who did Poplog devoted considerable effort to
solving this problem, with fair success, although Poplog has got more
fragile since a whole slew of widgets written in C were integrated into the
system and made user-available [A Poplog process used to stay up for days
or weeks in the good-old pre-X days] Some of this fragility has to be
attributed to the general flakiness of X-widget sets, particularly if used
in the rather dynamic way that Poplog uses them. However the basic concept
that Sussex used, of providing a mechanism for staticising data that the
foreign function may get hold of and keep between function calls, actually
works.
Otherwise what's required is care to ensure that the layout of data created
by the functional language system can match that of the non-functional
language system. Poplog, while it uses a tagging system, employs a version
in which pointers are not tagged, so make sense to the foreign language.
With a byte-addressed machine architecture this can be done by using the
l.s. 2 bits as tag bits, supporting 30-bit integers and floats. Other
data-descriptor information is placed before the object pointed to.
However, for the 90's I think that the JVM-style architecture offers more.
Essentially this is an untagged system with type-specific virtual-machine
operations.
That said, POPLOG is one system in which SML has available the necessary
apparatus for a foreign function interface.
Of course, whether a relocating garbage-collector makes sense is another
issue. Performance-wise it tends to give better locality. In fact the extra
degree-of-freedom of garbage-collected systems may offer significant
performance gains over traditional malloc-y systems if properly exploited.
With modern architectures, you can obey quite a few instructions for the
price of a cache-miss, not to mention a page-fault. On the other hand
relocation is a transaction that must go to completion before the system is
in a valid state for any other processing. So real-time performance is
awful.
Incidentally, stack-storage is not necessarily better than
garbage-collected storage. Eliot Moss at UMASS (or one of his students) did
some work recently to quantify this - with certain kinds of cache, heap
allocation may be highly efficient.
Robin.
|