[m-rev.] for review: printing higher order values and typeinfos in the debugger

[Fergus Henderson]

On 22-Feb-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> +++ library/deconstruct.m	22 Feb 2002 05:12:09 -0000
> @@ -55,7 +55,8 @@
>  	%	  the [....] shorthand.
>  	%	- for user-defined types with user-defined equality, the
>  	%	  functor will be of the form <<module:type/arity>>/0, except

I think the "/0" doesn't belong there.

> +++ runtime/mercury_type_info.h	22 Feb 2002 07:12:26 -0000
> @@ -1243,6 +1243,19 @@
> +
> +/*
> +** MR_collapse_ctor_equivalences expands out all the top-level equivalences in
> +** the argument type constructor. It guarantees that the returned type
> +** constructor will not have a MR_TYPE_CTOR_REP_EQUIV* representation.
> +** However, it is possible that a chain of equivalences ends in a type
> +** variable. If this happens, MR_collapse_ctor_equivalences will return NULL.
> +**
> +** You need to wrap MR_{save/restore}_transient_hp() around
> +** calls to this function.
> +*/
...
> +MR_TypeCtorInfo
> +MR_collapse_ctor_equivalences(MR_TypeCtorInfo type_ctor_info) 
> +{
> +	MR_PseudoTypeInfo	pseudo_type_info;
> +	
> +		/* Look past equivalences */
> +	while (MR_type_ctor_rep(type_ctor_info) == MR_TYPECTOR_REP_EQUIV_GROUND
> +		|| MR_type_ctor_rep(type_ctor_info) == MR_TYPECTOR_REP_EQUIV)
> +	{
> +
> +		pseudo_type_info = MR_type_ctor_layout(type_ctor_info).
> +			layout_equiv;
> +		if (MR_PSEUDO_TYPEINFO_IS_VARIABLE(pseudo_type_info)) {
> +			return NULL;
> +		}
> +
> +		type_ctor_info =
> +			MR_PSEUDO_TYPEINFO_GET_TYPE_CTOR_INFO(pseudo_type_info);
> +	}
> +
> +	return type_ctor_info;
>  }

This is wrong.

For example, if I have

	:- type foo(X, Y) == bar(Y, X).

then the type constructor foo/2 is definitely not equivalent to
the type constructor bar/2.  Likewise for many other examples, e.g.

	:- type foo(X, Y) == bar(int, pair(Y, float)).

The only case when it might be legitimate to treat two different
type_ctor_infos as equivalent is when the equivalence type is
of the form

	:- type foo(V1, V2, ..., VN) == bar(V1, V2, ..., VN).

where V1, V2, ..., VN are all type variables.

But IMHO it would be best to never treat distrinctly-named type_ctor_infos
as equal.  There's no *need* to treat them as equal (the need to do so only
arises for type_descs).  And treating type_ctor_infos differently
from type_ctor_descs would be confusing.

> --- runtime/mercury_ml_expand_body.h	21 Feb 2002 06:36:21 -0000
> +++ runtime/mercury_ml_expand_body.h	22 Feb 2002 07:33:41 -0000
> @@ -874,22 +874,29 @@
>          case MR_TYPECTOR_REP_TYPECTORINFO:
> +            {
> +                MR_TypeCtorInfo data_type_ctor_info; 
> +
> +                /*
> +                ** The only source of noncanonicality in typeinfos is due
> +                ** to type equivalences, Unfortunately, for type_ctor_infos,
> +                ** there is another source: after expanding out equivalences,
> +                ** the resulting `type' may be a type variable. Since the
> +                ** printable representation of this type variable is arbitrary,
> +                ** we avoid noncanonicality by always printing it the same way.
> +                ** Note that the outermost type_ctor_info cannot be a variable.
> +                */
...
> +
> +                if (noncanon == MR_NONCANON_ALLOW) {
> +                    data_type_ctor_info =
> +                        MR_collapse_ctor_equivalences(data_type_ctor_info);
> +                }
> +
> +                if (data_type_ctor_info == NULL) {
> +                    handle_functor_name("<<typevariable>>");
> +                } else {
> +                    handle_functor_name(MR_type_ctor_name(data_type_ctor_info));
> +                }
> +
> +            handle_zero_arity_args();

This is wrong because it uses MR_collapse_ctor_equivalences().

Also, don't you need to append "/<arity>" to the name returned
by MR_type_ctor_name()?

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------