[mercury-users] Circular lists

[Richard A. O'Keefe]

	> 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.

Ok, foreign code may do strange and terrible things _accidentally_
by overwriting arbitrary areas of storage.  But I'm talking about
breaching the rules of Mercury _without_ breaching the rules of the
foreign language.

	> 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.

No, no, and NO!  You don't get the point.
I'm having the same trouble in comp.std.c, where people seem to believe
that there are no real programs because every programmer is in complete
control of ALL the code s/he has to deal with.  It isn't true.

Remember the claim was that there are plenty of safe and useful ways to
use the foreign interface.  I'm not about to through the baby out with
the bath water.  

I would like tools to tell me _yes_ you are using the foreign interface
safely here, _beware_ that other third-party library may be doing something
dangerous.

	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.

The whole of Mercury is a fairly tricky implementation, but it's worth it.

	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??)

No, but it didn't give foreign code any way of tampering with Prolog data
or control WITHOUT BREACHING THE RULES OF THE FOREIGN LANGUAGE ITSELF.

	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.

Fine.

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

I just told you there weren't.  At the time I left, even *Quintus* couldn't
write dynamically loaded foreign code that accessed (let alone tampered
with) Prolog data structures.  It was *important* that there wasn't, as
that gave us freedom to use a compacting garbage collector.  Prolog data
structures might move anywhere at any time, as far as foreign code was
concerned.  Passing strings in either direction involved copying.

	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.

You insist on missing the point.  YES if the foreign code breaches its own
rules, anything can happen.

Something as simple as a list of interface functions and macros, saying
this subset has this risk level, and having the tool scan the code and
warn "you are using foo(), which is in the MAY-TRASH-TERMS set",
would go a long way towards what I want.

	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.

I would like the strongest guarantees I can afford; since I can't afford
very much I will be satisfied with simple 80% solutions.