[m-dev.] diff: type_name/1 et al

[Tyson Richard DOWD]

> 
> Provide Mercury predicates for manipulating types.
> Implement term_to_type/2.  Various other minor improvements.
> 
> library/std_util.m:
> 	- Add type `type_ctor_info', functions type_name/1, type_ctor/1,
> 	  type_args/1, type_ctor_name/1, type_ctor_arity/1, and make_type/2,
> 	  and predicates type_ctor_and_args/3 and type_ctor_name_and_arity/3.
> 	  Change type_of/1 so that it doesn't collapse equivalence
> 	  types; instead, do that in type_ctor/1 and type_ctor_and_args/3.
> 	- Change the definition of type `type_info' so that compare/3 and
> 	  unify/2 work for it.
> 	- Add functions univ/2, univ_type/1, and univ_value/1, and 
> 	  improve the documentation for type univ and associated predicates.
> 	- Use the `pragma c_code(...)' syntax rather than the old
> 	  `pragma(c_code, ...)' syntax.
> 
> library/mercury_builtin.m:
> 	- Add code to implement term_to_type/2.
> 	- Add a few comments.
> 	- Change the definition of type `c_pointer' so that
> 	  compare/3, unify/2 work for it, and so that deep_copy()
> 	  gives an appropriate error message if necessary.
> 
> -----------------------------------------------------------------------------
> Index: std_util.m
> ===================================================================
> RCS file: /home/staff/zs/imp/mercury/library/std_util.m,v
> retrieving revision 1.80
> diff -u -r1.80 std_util.m
> --- std_util.m	1997/04/26 08:20:59	1.80
> +++ std_util.m	1997/04/26 17:17:37
> @@ -1,5 +1,5 @@
>  %---------------------------------------------------------------------------%
> -% Copyright (C) 1995 University of Melbourne.
> +% Copyright (C) 1994-1997 University of Melbourne.
>  % This file may only be copied under the terms of the GNU Library General
>  % Public License - see the file COPYING.LIB in the Mercury distribution.
>  %---------------------------------------------------------------------------%
> @@ -27,22 +27,59 @@

This is a side issue, but should the whole libray be updated in this way? 
Or only when a file is modified?

>  :- type type_info.
> +:- type type_ctor_info.
>  
> -	% type_info(Data) returns the type_info of the type of Data.
> +	% (Note: it is not possible for the type of a variable to be an
> +	% unbound type variable; if there are no constraints on a type
> +	% variable, then the typechecker will use the type `void'.
> +	% 'void' is a special (builtin) type that has no constructors.
	  ^^^^^^

s/'/`

> +	% There is no way of creating an object of type `void'.
> +	% `void' is not considered to be a discriminated union, so the
> +	% functions get_functor/5 and construct/3 will fail if used
> +	% upon a value of this type.)

Strictly speaking, get_functor is a predicate, not a function. But
construct is a function. (Sometimes, this language would be a lot
simpler without functions ;-).

> +	% type_ctor_and_args(Type, TypeCtor, TypeArgs):
> +	%	True iff `TypeCtor' is a representation of the top-level
> +	%	type constructor for `Type', and `TypeArgs' is a list
> +	%	of the corresponding type arguments to `TypeCtor',
> +	%	and `TypeCtor' is not an equivalence type.
> +	%
> +	% For example, type_ctor_and_args(type_of([2,3]), TypeCtor,
> +	% TypeArgs) will bind `TypeCtor' to a representation of the
> +	% type constructor list/1, and will bind `TypeArgs' to the list
> +	% `[Int]', where `Int' is a representation of the type `int'.
> +	%
> +	% Note that the requirement that `TypeCtor' not be an
> +	% equivalence type is fulfilled by fully expanding any
> +	% equivalence types.  For example, if you have a declaration
> +	% `:- type foo == bar.', then type_ctor_and_args/3 will always
> +	% return a representation of type `bar', not type `foo'. 

Are you talking about types or type constructors? TypeCtor has the
requirement that it is not an equivalence type, so the example should be
in terms of type constructors, to avoid possible confusion.

>  :- func construct(type_info::in, int::in, list(univ)::in) = (univ::out)
>  		is semidet.

Should proably remove the mode qualifiers from this function, so that it
matches the other functions in appearance.

>  
> +:- type type_ctor_info == c_pointer.  	% XXX is that good enough?
> +					% XXX what about higher-order?

It's not clear what "good enough" means in this context - do you mean
expressive enough? Some more comments on these XXXs would be good.
Also, documenting that type_ctor_infos correspond to base_type_infos
would be good (we should probably change the name, so we use
type_ctor_info).

>	/*
>+	** ML_make_type(arity, base_type_info, arg_types_list):
>+	**
>+	** Construct and return a type_info for a type using the
>+	** specified base_type_info for the type constructor,
>+	** and using the arguments specified in arg_types_list
>+	** for the type arguments (if any).
>+	**
>+	** Assumes that the arity of the type constructor represented
>+	** by base_type_info and the length of the arg_types_list
>+	** are both equal to `arity'.
>+	*/

Document that you need to save and restore transient registers around
this code.

> +Word
> +ML_make_type(int arity, Word *base_type_info, Word arg_types_list) 
> +{
> +	int i;
> +
> +	/*
> +	** XXX: do we need to treat higher-order predicates as
> +	**      a special case here?
> +	*/

The type_infos for higher-order predicates have to store the arity of
the predicate in them. From the comments at the top of polymorphism.m:

% Higher order types:
%
% There is a slight variation on this for higher-order types. Higher
% order type_infos always have a pointer to the pred/0 base_type_info,
% regardless of their true arity, so we store the real arity in the
% type-info as well.
%
%       word 0          <pointer to the base_type_info structure (pred/0)>
%       word 1          <arity of predicate>
%       word 2+         <the type_infos for the type params, at least one>
%

There are probably a few places in std_util.m where this hasn't been
done properly.

Otherwise this is fine. When everything but the higher-order problems
are addressed, commit away.  (Later, we should look at higher order, and
fix any missing cases).

A test case for these features would be good.

-- 
       Tyson Dowd           #
                            #             Sign on refrigerator:
     trd at cs.mu.oz.au        #           Refrigerate after opening. 
http://www.cs.mu.oz.au/~trd #                  - C. J. Owen.