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

[Fergus Henderson]

On 25-Feb-2002, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 24-Feb-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > I agree, but should we also mention mdb's new print_optionals command?
> > 
> > Since this provides useful additional functionality, IMHO yes.
> 
> It is useful to implementors, but I don't think it is useful to ordinary users.
> Do you? Does anyone else?

I think it is useful to ordinary users in at least some cases, yes.

For example, for the `map' type we print out the type of the map
when an exception occurs.  This is useful information.
But for arrays we don't, due to efficiency concerns.
If an array index gets an exception, the information about the
type is available with the print_optionals command.

> > > I thought the comment already implied what you said.
> > 
> > Almost; but the problem is in std_util__deconstruct (and friends),
> > not in the debugger.
> 
> This part of the debugger is tightly coupled to the deconstruction predicates
> in the library; the debugger cannot easily do things that the deconstruction
> predicates do not do.

I think the comment is misleading, because it implies that the problem should
be fixed by modifying the debugger, which is not the case.

> > > 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?
> 
> I want to keep the existing definitions of MR_TypeInfo, MR_TypeCtorInfo and
> MR_PseudoTypeInfo, yes. However, the existing C definitions of type_desc
> and type_ctor_desc are clumsy, so there is no point in keeping them. Since
> they are not performance critical, it is ok for them to have a single
> implementation in Mercury.

Hmm. The speed of dynamic type checks may be performance critical for
some apps.  E.g. this is important for the speed of io__write...

Also, now that I look at it a bit closer, I don't see why type_desc/0
should be ignored.  I understand why special handling is needed for
type_ctor_desc/0.  But in the existing C back-end, type_desc/0 is
represented just as MR_TypeInfo.  Is there any reason why the current
code won't handle type_desc/0 correctly already?
Can't the first line after the comment in the code below be deleted?

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

If the issue is just type_ctor_desc rather than type_desc, it's much
less of a worry.

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