[mercury-users] Circular lists

[Fergus Henderson]

On Thu, Nov 27, 1997 at 12:24:19PM +1100, Richard A. O'Keefe wrote:
> 
> We've seen quite a few examples recently of how Mercury's C interface can be
> used to do strange and terrible things.

I don't think there's any realistic way for a system such as Mercury to
allow you to link in existing native-code libraries without also
allowing you to do strange and terrible things.

The code that Tom posted was an awful hack that uses implementation
details of the current Mercury implementation.  The documentation does
not in any way guarantee that it will work, and in fact I can guarantee
that it will break in a future release.

> I'm not into _forcing_ people to do what's good for them, but when using
> Mercury I would very much like to know for certain that nothing of the
> sort was going to affect my code.

Well, that's reasonably easy: don't use the foreign language interface,
don't use the `unsafe' module, and don't disable array bounds checks.

If you want to link in foreign native code, and you want guarantees
that nothing strange will happen, then you would need a fairly
tricky implementation.  I suppose the implementation could run
the foreign code in a different process, using IPC for the
foreign-language interface, but for a variety of reasons this
doesn't seem like a really great idea to me.

> Now the Quintus Prolog foreign interface was designed with the view that
> the main use for such an interface was to access _existing_ libraries
> (Fortran, Pascal, C &c), NOT to extend or change Prolog.  My slogan was
> "the foreign interface is a crook, so the Prolog shepherd can lift up
> the C sheep, not a crutch, for a strong C to prop up a weak Prolog".  
> Foreign code had no access to Prolog data structures, and the only control
> effects possible were to return, fail, or raise an exception.
> 
> That kind of interface _can't_ destroy the safety properties of a language
> like Mercury, and to be frank, that's the kind of interface I really want.

Although the design aims were not quite the same, I think the Mercury
foreign language interface has the same properties as the Quintus
Prolog foreign interface in this respect.  (Or am I mistaken --
does Quintus really run foreign code in a different process, or
do something equivalent??)

Accessing existing libraries was the main motivation for the Mercury
C interface.  However, there was also another (less important) motivation.
As well as accessing existing libraries in C and other languages, the
Mercury C interface was also intended for use by the Mercury
implementors to implement some low-level features.  Since we were
compiling to C, some of these low-level features were in fact already
implemented in C code, in a way that was even more tightly coupled to
the compiler's internal implementation details.  The C interface
provided a way for us to abstract away some of those details.

But that is all implementation details.  The documented C interface
does not provide ways for foreign code to access non-atomic Mercury
data structures; the way to do that is to write Mercury access procedures
and export them to C.

I strongly suspect that with Quintus Prolog, just as with Mercury, 
there were undocumented ways of accessing Prolog data structures
from C.

>     +---------------------------------------------------------+
>     | Is there some tool that can be used to verify that the  |
>     | Mercury foreign interface has been used in a useful but |
>     | disciplined way that CAN'T break Mercury's type system, |
>     | mode system, termination verification, or other safety  |
>     | features?                                               |
>     +---------------------------------------------------------+

I'm afraid not.  I agree with the desirability of this goal,
but it doesn't look easy.  Any language such as C, C++, or even
(if you compile with runtime checking disabled) Ada, which all allow
assigning to a dereferenced uninitialized pointer, has the potential to 
break Mercury's type system.  I guess doing a JVM backend for the Mercury
compiler would be the first step...

Maybe what you want is actually a weaker (hence more achievable)
guarantee, but I'm not sure exactly what the guarantee would be,
or how to achieve it.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   WWW: <http://www.cs.mu.oz.au/~fjh>  
Note: due to some buggy software and a (probably accidental)
denial-of-service attack, any mail sent to me between
	Tue Nov 25 20:00:00 UTC (6am Wed, local time)
and	Wed Nov 26 06:00:00 UTC (4pm, local time)
may have gone into the bit-bucket.  Please re-send it.