[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