[m-rev.] for review: native types in table_builtin.m

[Zoltan Somogyi]

On 12-Nov-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> That explains why you need the Mercury definition, but not why you
> need the il definition.

This change is several months old. When I first wrote it, it was needed
to pass IL test cases. The reason why it is still needed is to make
the type a foreign type; see below.

> > No. From Mercury, the type is an abstract type; its values are not manipulated
> > by Mercury-generated C code, only by hand-written C code.
> 
> The type has a type_ctor_info which can be referred to from other modules.
> Other modules can call unify, compare, or std_util__deconstruct for
> values of this type.

They can't get their hands on a value of this type. The type is private
to table_builtin, and table_builtin doesn't have any predicates that return
values of these types without requiring another value of these types first.
The compiled codes of table procedures get around this by using the
compiler-generated reference to the compiler-generated table root pointer.
This is not a means that is available to user code.

> Such calls will fail in ".rt" grades, I believe.

It doesn't matter if all calls in the empty set fail.

Besides you can't actually deconstruct either c_pointers or foreign types;
in both cases an attempt will get you a placeholder. Changing the type from
c_pointer to a foreign type thus changes nothing.

Deconstructing ml_table(c_pointer) would indeed fail. This is why we want
these types, ml_table and ml_answer_list, to be foreign types on all platforms.
My changes goes as far in this direction as currently possible, given the
current absence of support for Java foreign types.

> Are you sure that the debugger will never call io__print_cc on such values,

Yes, see above.

> thus accessing the (incorrect in ".rt" grades) type_ctor_info?

The type_ctor_info isn't incorrect; on all backends except Java, it says
the type is a foreign type, which it is.

Zoltan.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------