[m-rev.] diff: handle user defined equality in rtti_implementation__deconstruct

[Fergus Henderson]

On 30-Nov-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> fjh wrote:
> > On 29-Nov-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> > > fjh wrote:
> > > > On 29-Nov-2002, Peter Ross <pro at missioncriticalit.com> wrote:
> > > > > +handle_usereq_type(Term, TypeInfo, TypeCtorInfo,
> > > > > + TypeCtorRep, NonCanon, Functor, Arity, Arguments) :-
> > > > > + ( NonCanon = do_not_allow,
> > > > > + error("attempt to deconstruct noncanonical term")
> > > > > + ; NonCanon = canonicalize,
> > > > > + Functor = expand_type_name(TypeCtorInfo, yes),
> > > > > + Arity = 0,
> > > > > + Arguments = []
> > > >
> > > > The two lines above look wrong -- there should at least be an XXX
> comment
> > > > there.
> > > >
> > >         case MR_TYPECTOR_REP_ENUM_USEREQ:
> > >             if (noncanon == MR_NONCANON_ABORT) {
> > >                 /* XXX should throw an exception */
> > >                 MR_fatal_error(MR_STRINGIFY(EXPAND_FUNCTION_NAME)
> > >                     ": attempt to deconstruct noncanonical term");
> > >                 break;
> > >             } else if (noncanon == MR_NONCANON_ALLOW) {
> > >                 handle_noncanonical_name(type_ctor_info);
> > >                 handle_zero_arity_args();
> > >                 break;
> > >             }
> > >             /* else fall through */
> > >
> > >         case MR_TYPECTOR_REP_ENUM:
> > >             handle_functor_name(MR_type_ctor_layout(type_ctor_info).
> > >
> MR_layout_enum[*data_word_ptr]->MR_enum_functor_name);
> > >             handle_zero_arity_args();
> > >             break;
> > >
> > > Here is the C code from mercury_ml_expand_body.  As you can see in
> > > MR_NONCANON_ALLOW case, we expand the type name and return 0 arity.
> > > Consequently the Arguments should be the empty list.
> >
> > For enums, fine -- all values of enumeration types are constants
> > and thus have zero arity.
> >
> > But the procedure you are defining here doesn't say anything in its
> > name about only being valid for enums, and in your code it gets called
> > for du types, not just enum types.
> >
> If you examine the code for all the other cases in mercury_ml_expand_body.h
> it does exactly the same thing.  It may not be the correct thing to do, but
> that is what the code in ml_expand_body.h does.

No it doesn't.

See line 424 (in case MR_TYPECTOR_REP_DU):

	expand_info->arity = functor_desc->MR_du_functor_orig_arity;


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