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

Zoltan Somogyi zs at cs.mu.OZ.AU
Mon Feb 25 00:09:51 AEDT 2002


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

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

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



More information about the reviews mailing list