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

[Peter Ross]

On Thu, Nov 20, 2003 at 10:38:07PM +1100, Simon Taylor wrote:
> 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.
>  
It isn't wrong, there is always a unification predicate generated but is
that predicate generated by unify_proc or defined out-of-line in C#?

This bit of code tests is there an implementation in Mercury for the
unification and comparison predicates for these types?

As there is no private_builtin.builtin_unify_func the Mercury compiler
generates a call to mercury.builtin.special__Unify__func_0_0 which then
calls mercury.builtin.special__Unify__func_0_0, where this deep magic
occurs I am not sure.

However there is a mercury predicate builtin_unify_pred which unifies
pred so in that case we generate for the Unify predicate for pred/0
(maybe the name is wrong, but that is what we had before in the code)
which simply calls private_builtin.builtin_unify_pred.

Look in add_special_preds in make_hlds.m to see the two different cases
for adding the special_pred explained above.

Does this help?

> > > 
> > > 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?
>  
The snipped code that you deleted fixes the problem.

However the best solution in the long run would be to make everything
builtin a foreign_type.  This would require adding a new annotation to
the foreign_type which declared that there was only one representation
for equal types to avoid the problems mentioned in the User Manual
<http://tinyurl.com/vte6>.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------