[m-rev.] for review: field names and higher order values in the debugger
Fergus Henderson
fjh at cs.mu.OZ.AU
Wed Dec 19 19:25:28 AEDT 2001
On 19-Dec-2001, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 19-Dec-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > Deconstruct closures as if they were ordinary terms, with the function
> > > symbol being the name of the predicate/function and the arguments being
> > > the terms stored in the closure.
> >
> > Allowing deconstruction of closures breaks referential transparency for
> > std_util__deconstruct and the like.
>
> Actually, deconstruction already breaks referential transparency for DU terms
> with variable tags (for HAL),
True, but HAL isn't referentially transparent anyway.
> for c_pointers, typeinfos, typeclassinfos etc.
Nope, the way it currently handles those preserves referential transparently
just fine, I'm pretty sure.
I would really prefer it if we don't commit changes that introduce
known regressions.
> > > +++ runtime/mercury_ml_expand_body.h 2001/12/18 03:33:42
> > > @@ -549,8 +621,88 @@
> > >
> > > case MR_TYPECTOR_REP_PRED:
> > > /* XXX expand_info->non_canonical_type = TRUE; */
> >
> > After your change, the code inside the comment there is needed.
>
> I will uncomment that code when I add cc_multi versions of the deconstruction
> predicates, probably next week. Before that, uncommenting would cause an abort
> when trying to deconstruct closures.
One way to make it work correctly without introducing a bunch
of new predicates would be to set a global boolean variable in
trace/mercury_trace_browse.c before calling the browser, and to unset
it afterwards. Then the code here could be
if (MR_called_from_browser)
... old code ...
} else {
... your new code ...
}
That's a bit of a hack, but I think it's better than introducing a known
regression.
--
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
--------------------------------------------------------------------------
More information about the reviews
mailing list