[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:
> On 22-Feb-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > The changes to io.m should be mentioned in the NEWS file.
> 
> I agree, but should we also mention mdb's new print_optionals command?

Since this provides useful additional functionality, IMHO yes.

> > I don't think type_ctor_infos are a non-canonical type, are they?
> 
> They are, for the same reason type_infos are: the type constructor may specify
> an equivalence, so map/2 and tree234/2 are the same constructor.

Well, it would be possible to do things that way, but IMHO it would be
better to treat distinctly named type constructors as being distinct.
The nondeterminism comes when extracting the type_ctor_info from the
type_info.

Note that for type_ctor_desc, we definitely treat distinctly named type
constructors as being distinct (otherwise the function type_ctor_name/1
would have to be a cc_multi predicate rather than a function).
It would be confusing to handle type_ctor_infos different than we handle
type_ctor_descs.

Note that the code which you posted for handling equivalences of
type_ctor_infos is wrong (see my other post).

> > > Index: trace/mercury_trace_vars.c
> > >  static	MR_TypeCtorInfo
> > > +MR_trace_always_ignored_type_ctors[] =
> > >  {
> > > +	/* we ignore these until the debugger can handle their varying arity */
> > >  	&mercury_data_type_desc__type_ctor_info_type_desc_0,
> > >  	&mercury_data_type_desc__type_ctor_info_type_ctor_desc_0,
> > 
> > These should not be ignored; they are useful to the user, and if
> > std_util__deconstruct can't handle them, that is a bug which should
> > be fixed.
> > 
> > So at very least there should be an XXX with that comment.
> 
> I thought the comment already implied what you said.

Almost; but the problem is in std_util__deconstruct (and friends),
not in the debugger.

> However, the right fix
> is not to make the debugger handle those types in their existing definitions;
> it is to make those type proper Mercury types, along the lines of the
> Mercury-defined type_info and type_ctor_info structures I showed you a week
> or two ago.

I thought you wanted to keep the existing definitions for the C back-end,
even if we add Mercury definitions for other back-ends?

If that's the case, then std_util__deconstruct will need to handle
the current definitions, so that it works for the C back-end.

-- 
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
--------------------------------------------------------------------------