[m-rev.] for review: automatically generate all type_ctor_infos on non C backends

[Simon Taylor]

On 20-Nov-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> On Thu, Nov 20, 2003 at 01:40:44PM +1100, Fergus Henderson wrote:
> > On 19-Nov-2003, Peter Ross <pro at missioncriticalit.com> wrote:
> > > Get the compiler to generate the type_ctor_infos for all the types
> > > which were previously defined by hand.
> > > 
> > > This change completes the removal of all the MC++ from the compiler.
> > 
> > Good stuff, Pete.  Thanks!
> > 
> > > Index: compiler/special_pred.m
> > ...
> > >  can_generate_special_pred_clauses_for_type(ModuleInfo, TypeCtor, Body) :-
> > > -	Body \= abstract_type(_),
> > > +	(
> > > +		Body \= abstract_type(_)
> > > +	;
> > > +		% Only the types which have a unification defined in
> > > +		% private_builtin.m
> > > +		compiler_generated_rtti_for_the_builtins(ModuleInfo),
> > > +		Builtin = mercury_public_builtin_module,
> > > +		( TypeCtor = qualified(Builtin, "int") - 0
> > > +		; TypeCtor = qualified(Builtin, "string") - 0
> > > +		; TypeCtor = qualified(Builtin, "character") - 0
> > > +		; TypeCtor = qualified(Builtin, "float") - 0
> > > +		; TypeCtor = qualified(Builtin, "pred") - 0
> > > +		)
> > 
> > XXX There should be a comment in private_builtin.m pointing to this code.
> > XXX Treating pred/0 specially here seems odd and possibly wrong;
> >     what about func/0, pred/1, etc.?
> > 
> pred/0 is treated specially here because it has a unification procedure
> defined in private_builtin.m, while pred/1 and func/0 don't.  Maybe the
> definition of private_builtin.builtin_unify_pred should mention pred/1
> instead?

I'm pretty sure your code here is wrong.
There is one MR_TypeCtorInfo (and hence unification predicate) for each
of pred/N, func/N and {}/N.
 
> > > +++ compiler/type_ctor_info.m	19 Nov 2003 14:12:28 -0000
> > > @@ -111,10 +111,23 @@
> > >  			TypeModuleName = ModuleName,
> > >  			map__lookup(TypeTable, TypeCtor, TypeDefn),
> > >  			hlds_data__get_type_defn_body(TypeDefn, TypeBody),
> > > -			TypeBody \= abstract_type(_),
> > > -			\+ type_ctor_has_hand_defined_rtti(TypeCtor, TypeBody),
> > > -			( are_equivalence_types_expanded(ModuleInfo)
> > > -				=> TypeBody \= eqv_type(_) )
> > > +			(
> > > +				TypeBody \= abstract_type(_),
> > > +				\+ type_ctor_has_hand_defined_rtti(TypeCtor,
> > > +					TypeBody),
> > > +				( are_equivalence_types_expanded(ModuleInfo)
> > > +					=> TypeBody \= eqv_type(_) )
> > > +			;
> > > +				compiler_generated_rtti_for_the_builtins(
> > > +					ModuleInfo),
> > > +				TypeModuleName = unqualified(ModuleNameString),
> > > +				( builtin_type_ctor(ModuleNameString,
> > > +					TypeName, TypeArity, _)
> > > +				; impl_type_ctor(ModuleNameString,
> > > +					TypeName, TypeArity, _),
> > > +				  TypeName \= "ticket"
> > > +				)
> > > +			)
> > 
> > Please add some comments here.
> > 
> > I don't understand why we need to special-case "ticket";
> > that looks like it might be a bug.
> > 
> It is to do with the fact that ticket is defined as having an
> impl_type_ctor but it's definition is
> 
> :- type ticket == c_pointer.
> 
> What I have done is change the code to the following, which means that
> we only generate type_ctor_infos for the builtin types which are
> abstract.

Would making `ticket' a foreign type rather than an equivalence remove
some of the special casing?
 
Simon.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------