[mercury-users] Self-referential data structures

Richard A. O'Keefe ok at cs.rmit.edu.au
Wed Nov 26 12:23:04 AEDT 1997


	RCS file: /home/mercury1/repository/mercury/library/store.m,v
	retrieving revision 1.8
	diff -u -u -r1.8 store.m
	--- store.m	1997/11/20 05:59:20	1.8
	+++ store.m	1997/11/25 14:45:17
	@@ -75,6 +75,12 @@
	 :- pred store__set_mutvar(mutvar(T, S), T, store(S), store(S)).
	 :- mode store__set_mutvar(in, in, di, uo) is det.
	 
	+	% return a `null' mutvar.
	+	% Note: any attempt to get or set the value stored in a null mutval
	+	% will result in undefined behaviour (typically a segmentation fault).
	+:- pred store__null_mutvar(mutvar(T, S), store(S), store(S)).
	+:- mode store__null_mutvar(out, di, uo) is det.
	+
	+	% null_ref(Ref): return a `null' reference.
	+	% Note: any attempt to dereference such a null reference
	+	% will result in undefined behaviour (typically a segmentation fault).
	+:- pred store__null_ref(ref(T, S), store(S), store(S)).
	+:- mode store__null_ref(out, di, uo) is det.
	+

I am deeply unhappy about this.
It's not so long since I chewed out the Clean people because their
system gave a segfault when a valid program ran out of memory.
One of the reasons I loved Prolog in the first place was that with a
product like Quintus Prolog, as long as you stuck with Prolog, and didn't
add your _own_ foreign code, you *never* got a machine fault.
You were programming in a model where just about all the things that could
raise machine exceptions (other than arithmetic exceptions) were inexpressible.

If an operation doesn't make sense, then Mercury should produce an
_intelligible_ error message when it happens.  
	"foo/5;2: Attempt to get value stored in a null mutvar"
is a good response.
	"Segmentation fault, core dumped."
is not.

Zoltan keeps on telling me that Mercury isn't about making logic programming
go fast, it's about *software engineering*, about making it easier to write
and maintain programs that *work*.  If that is true, then it is really
important that Mercury should have good run-time diagnostics that make it
straightforward to find out what the symptom was and where it occurred.

We could live with segfaults and other UNIX traps ONLY
IF there were a version of gdb that understood Mercury, and could interpret
core dumps in Mercury terms.








More information about the users mailing list