why arrays etc. need to be builtin types

[Fergus Henderson]

Hi Tyson & anyone else interested,

deep_copy() currently doesn't know about the arrays defined in uniq_array.m.
That means that if you use a non-gc grade, and you use solutions/2 to
get all the solutions to a predicate that returns arrays, things will break.

On a similar note, defining type_info == c_pointer means that unification
doesn't work for type_infos, so `type_of(X) = type_of(Y)' can give
wrong results, which is a bummer, since I need to use that construct
to make io__read work for arrays.  type_info also has the same problem with
deep_copy() that uniq_array has.

Hence I'm going to make c_pointer and type_info new builtin (defined in C)
types, and I'm going to define typelayout values for those two and for
uniq_array.  I'm going to change deep_copy() to handle these types. 
I'm not quite sure what is the right thing to do for c_pointer.
I think I will get it to check whether the pointer is in_range()
(i.e. allocated on the Mercury heap, in the area that needs to be copied);
if so, it will abort with an error message, otherwise it will just
return the original pointer.

Here's the full list of builtin types:

	int
	character (char)
	float
	string

	void

	type_info
	univ
	uniq_array
	io__stream (== c_pointer)
	io__external_state (== c_pointer)

	c_pointer

Everything else is one of the following:

	pred types
	func types

	discriminated unions

	equivalence types

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.