[m-dev.] for review: add type_ctor_reps for user-defined equality

[Tyson Dowd]

On 28-Oct-1999, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> Tyson wrote:
> > +** Note: next time the binary compatibility version number is increased,
> > +** we should remove the MR_get_new_type_ctor_rep() function in
> > +** runtime/mercury_type_info.c.  
> 
> It would be a good idea to do this before the next release, in order to
> remove the overhead of the calls to MR_get_new_type_ctor_rep.

I expected that the binary compatibility number would be bumped up
before the release.  Perhaps it needs to be on the release checklist or
something?

> 
> > +		case MR_TYPECTOR_REP_ENUM_USEREQ:
> >  		case MR_TYPECTOR_REP_DU:
> > +		case MR_TYPECTOR_REP_DU_USEREQ:
> >  		case MR_TYPECTOR_REP_ARRAY:
> >  		case MR_TYPECTOR_REP_NOTAG:
> > +		case MR_TYPECTOR_REP_NOTAG_USEREQ:
> >  		case MR_TYPECTOR_REP_EQUIV:
> >  		case MR_TYPECTOR_REP_EQUIV_VAR:
> 
> This should enable you to undo Fergus's action in disabling the use of this
> code. You definitely want to check that this would work; you may want to wait
> committing that until we can delete MR_get_new_type_ctor_rep, or redefine it
> as an identity macro.

I think it would be best to wait until this test has fully bootstrapped
before we rely upon the _USEREQ to catch all user defined equality
types.

> However, I think you should treat ENUM_USEREQ conservatively (i.e. call the
> procedure in the type_ctor_info) not just for unifications but also for
> index and comparison operations as well. For example, the auto-generated
> comparison predicate for types with user-defined equality calls error;
> it does not return.

Done.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------